Security hardening: update-integrity trust chain and local control-socket authentication

[juliogc]

Two trust boundaries in master are currently open: the auto-updater installs binaries it never cryptographically verifies, and the local control socket accepts any peer that can reach it. Either one is a code-execution path — supply-chain for the first, local privilege for the second.

Details below. I'm happy to implement the fixes if the direction is approved.

1. Auto-update has no cryptographic trust in the downloaded binary (src/update.rs)
The updater's only integrity guarantee is TLS to herdr.dev, and it can be bypassed:

• No publisher signature on release artifacts (CWE-347) — a SHA-256 in the manifest detects corruption, not a spoofed/compromised source.
• The checksum is optional (sha256: Option<String>) — if a manifest entry omits it, the binary installs with no content check at all (CWE-494).
• Asset URLs aren't scheme-validated and are fetched with curl -sfL, so http:// is accepted and https:// can be redirect-downgraded (CWE-494).

Together these turn an origin/CDN compromise, a mis-issued TLS cert, or a network MITM into code execution on next launch. Direction I'd propose: sign artifacts with an offline key + verify before install, make the integrity check mandatory, and pin the transport to HTTPS with no downgrade.

2. Local control socket has no peer authentication (src/ipc.rs, src/api/server.rs)
Access control is filesystem-only (chmod 0o600 applied after bind, leaving a race window), with no SO_PEERCRED/getpeereid check, and no ACL on the Windows named pipe. On a shared host another local account can reach the full API (keystroke injection into agent panes, process spawn, server stop). Direction I'd propose: peer-UID assertion on accept + tighten the bind so the socket is never briefly world-accessible, and a per-user SID ACL on Windows.

I have file/line-level notes and suggested fixes ready. If either direction sounds right, let me know how you'd like to proceed (convert to issue, private disclosure, etc.) and I'll pick it up.

Environment

• Herdr version: 0.7.1
• Operating system: macOS (Darwin 25.5.0)
• Terminal: Ghostty 1.3.1
• Shell: zsh 5.9 (arm64-apple-darwin25.0)

[juliogc]

@ogulcancelik my apologies in tagging you in this thread, but I really would like to discuss some security issues which I found analyzing the project and that restricting me to keep using it in my enterprise life due to security compliance.

I wouldn't like to break the trust you gave me as a contributor and starting spamming PRs, so that's why I started this thread.

I'm always up to contributing to herdr to make more people able to use it.

[acarril]

Adding a data point from the enterprise-adoption side, since this is still open at 0.8.0. Both items are unchanged in v0.8.0. Verified against the tag:

• src/update.rs: sha256 is still Option<String> (L127) and verification still sits inside if let Some(expected) (L586). Download is still curl -sfL with no --proto '=https' --proto-redir '=https' (L574)
• src/api/server.rs: still bind-then-chmod (L82-83), and handle_connection (L139) dispatcches straight from the first JSON line with no peer check.
• src/ipc.rs — restrict_socket_permissions on Windows is still Ok(()) (L284), so no named-pipe ACL.

Another issue worht mentioning is that the optional-checksum path isn't hypothetical on stable: https://herdr.dev/latest.json publishes assets as flat URL strings with no sha256 key, so sha256 resolves to None and herdr update installs with no content check at all. preview.yml does compute per-artifact checksums (preview-sha256.json) — stable is the channel without them. website/install.sh doesn't verify either; its # verify step is just a PATH check.

Separately, and maybe the bigger adoption blocker: the release binaries aren't code-signed. On the 0.8.0 macOS build, codesign -dvvv reports Signature=adhoc / TeamIdentifier=not set, and spctl -a returns rejected. No Authenticode on the Windows artifacts. Between that and a self-updater that downloads an executable, chmod 0o755s it, and renames it over the running binary, herdr trips both app-allowlisting policy (Jamf/Gatekeeper, WDAC/AppLocker) and EDR heuristics — which is what keeps it out of managed fleets regardless of whether anything is actually wrong.

Cheapest wins first, if useful:

1. Publish SHA256SUMS for stable and make the check mandatory (fail closed when absent).
2. actions/attest-build-provenance in release.yml. This is near-zero cost, and it's what security reviews increasingly ask for. (repos/herdrdev/herdr/attestations 404s today.)
3. Pin the transport: --proto '=https' --proto-redir '=https'.
4. Developer ID + notarization / Authenticode — bigger lift, but it's the one that unblocks managed installs.