Fourth marketplace review round: cross-uid path fix in the client and an honest authorization boundary.
Security
omarchy-protonmail-recentno longer falls back to/tmpwhenXDG_RUNTIME_DIRis unset: it refuses to run (exit 1), mirroring the broker. The predictable runtime path under a world-writable directory — where a different local user could pre-create the directory and serve arbitrary JSON — is gone from both halves of the pair, not just one.omarchy-protonmail-recentnow connects to the broker socket the same way the broker creates it: relative to a directory descriptor opened withO_NOFOLLOW, after validating ownership and0700mode ofXDG_RUNTIME_DIRand the broker subdirectory, and the socket type and ownership (statwithfollow_symlinks=False). The connect path is/proc/self/fd/<dirfd>/broker.sock, so nothing on disk is re-resolved at connect time.omarchy-protonmail-broker: the/proc/<pid>/exe+argv[1]peer checks were removed. They were not an authorization boundary — any same-uid process can execute the real client script and satisfy them by construction — and they introduced a pid-reuse window betweenaccept()and the/procreads. The boundary is now stated as what it is:SO_PEERCRED(peer uid equals the broker's euid), captured atomically at accept time, over a0600socket inside a0700per-user runtime directory. Every same-uid process is inside that boundary by construction (it can ptrace the broker and reach its CDP pipe fds), so no handshake can exclude it; the API therefore grants nothing beyond same-uid reach — read-onlyrecent, size- and row-capped replies, and every dangerous capability (JavaScript execution, session cookies, full mailbox access) stays inside the broker process. The broker and client docstrings state this residual explicitly.
Verified live
omarchy-protonmail-recentwithoutXDG_RUNTIME_DIRrefuses (exit 1).- With the webapp open and signed in:
{"open": true, "loggedIn": true, "messages": [...]}with real truncated rows. omarchy plugin validateexit 0 at this version.