Single-instance IPC uses a hardcoded PIPE_AUTHKEY

[Orinks]

Summary

activation_ipc.py ships a static authkey for the duplicate-launch activation pipe:

DEFAULT_PIPE_ADDRESS = r"\.\pipe\AccessiWeather.SingleInstance.Activation"
PIPE_AUTHKEY = b"AccessiWeather.SingleInstance.v1"

The pipe lives at machine scope, and because the authkey is a compile-time constant in the repo, any local process can complete the multiprocessing.connection auth handshake and send activation requests.

Risk: low (today)

The blast radius is currently small: a sender can only trigger UI actions (show the window, open an alert/discussion dialog), and the server uses send_bytes/recv_bytes + JSON rather than pickle, so there's no code-execution path. Deferred deliberately during the single-instance review for that reason.

When this matters

If the set of IPC request kinds ever grows to include anything with side effects beyond raising UI, revisit this. The fix is to derive the key per-user instead of shipping a constant — e.g. from the user SID or the runtime storage path — so a request can't be forged across user sessions.

Context

Came out of the single-instance startup review (finding #4). Related PRs: #698 (handle truncation), #699 (handoff dedupe / polling).

[Orinks]

Closing as accepted risk for now (decision: don't implement yet).

Rationale:

• Local-only reach. The pipe is machine-scoped, but the OS already restricts a multiprocessing AF_PIPE to the creating user's context in practice, so this isn't an open cross-user channel today.
• UI-only effect. The worst a forged request can do is show the window or open an alert/discussion dialog — no state mutation.
• No deserialization path. The server uses send_bytes/recv_bytes + JSON, not pickle, so there's no code-execution surface even with a valid authkey.

Trigger to revisit / reopen: if the set of IPC request kinds ever grows to include anything with side effects beyond raising UI. At that point, switch to a per-user key — generate a random token on first run, store it in the user's profile-protected config dir, and have both instances read it instead of shipping the constant PIPE_AUTHKEY.

Context: surfaced in the single-instance startup review alongside #698 (handle truncation) and #699 (handoff dedupe), both now merged to dev.