forked from unom/punktfunk
enricobuehler
0df4ca957f
`service install` added `dir=in action=allow` rules carrying only `localport=`, which admit ANY process on the machine on those ports — GameStream (47984/47989/47998-48010/48010), the native plane (9777), mgmt (47990), mDNS (5353), and the console pair (47992/47993). Binding a high port on Windows needs no elevation, so an unprivileged program could take any of them and be reachable from the LAN simply by binding first — silently, because our rule is precisely what suppresses the "Allow this app to communicate on…" prompt that would otherwise be the only way in. Scope every rule to the executable that actually listens on it, keeping the ports: program AND port is strictly tighter than either alone. The host rules name the host exe (resolved once and shared with the data-plane rule, which already worked this way and is the pattern the rest now follow); the console rules name the bundled `<app>/bun/bun.exe` the supervisor spawns. The old argument for leaving them unscoped — "an install whose recorded exe path later moves still has its fixed ports open" — does not hold: `service install` re-runs this whole remove-then-add on every upgrade, so the path is refreshed rather than left stale. Fallbacks are deliberate and asymmetric. A fixed-port rule whose program can't be resolved falls back to the old any-program form, because a looser rule still streams and no rule is a black screen. The data-plane rule instead skips: it has no `localport=` to fall back to, so a program-less version of it would not be a looser rule but an open host. One externally visible change, called out in installer output: 5353 is ours alone now, so anything else on the machine that answered mDNS through punktfunk's rule needs its own. Reported by a user on 2026-08-21, after the source-IP fix in #367 resolved their black screen.