1.8 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-22 |
086 — Taking a module narrows a port the predecessor served, without saying so
What was observed
In the adoption lab bed, 2026-09-22. A service found on the machine served its port to anyone, and the predecessor's firewall allowed it from anywhere. The catalogue module that replaces it declares the port reachable from the private network only. After the module was taken, the mesh's guard refused that port from everywhere outside the private network. That is ADR 0103 working as written: a taken module's published private-network ports are guarded. The service answered over the private network, and the bed passed.
Nothing said the port had narrowed. Taking a module names the files and containers it replaces, but not the ports whose reach changes. The converge preview names every narrowing, but the flip comes after taking, so by then the change has already happened.
Why it matters beyond this instance
On a machine in use, taking a module is the cutover for that service. If the predecessor served the port publicly and the module says private, taking it closes the port to every client outside the private network. Nothing warns the operator first. ADR 0100 promises that each step says what it changes before it changes it, and for taking a module this one does not.
Open questions
- Should taking a module preview the reach of each port it publishes, found firewall and guard included, and ask for the same kind of confirmation as the flip?
- Or should taking refuse while a port of the module is reachable more widely than the module declares, until the operator either changes the module's exposure or confirms the narrowing?