hermes - 💡(How to fix) Fix Hardening: verify a signed tag / pinned hash before hermes update builds & installs the pulled tree

<!-- Suggested title: Hardening: verify a signed tag / pinned hash before `hermes update` builds & installs the pulled tree -->

Filed as a §3.2 hardening proposal (regular issue/PR), not a §3.1 report — the local-write preconditions (e.g. a repointed origin) are inside the trust envelope, and OS-isolation is the documented boundary. This asks to extend the supply-chain-guard instinct §4 already describes (CI guards for dependency/bundled-package changes) to the runtime self-update path.

Observation

hermes update does git pull --ff-only (or hard-reset on ff-fail) and then builds and installs the pulled tree: editable uv pip install -e .[all], npm/web build, optional Electron build, bundled-skill copy. The only check between pull and execute is a syntax parse of 8 files (_validate_critical_files_syntax over _UPDATE_CRITICAL_FILES, in hermes_cli/main.py). There's no git verify-commit / merge.verifySignatures, pinned SHA, or release-hash check.

So the trust in "the official origin/release" has no cryptographic verification at update time — a compromised upstream or a force-push to the resolved remote is built and installed as-is. (OFFICIAL_REPO_URLS exists but only drives a non-blocking fork warning via _is_fork, never a gate.)

Suggested improvements

1. Anchor the pulled tree before build/install — verify a signed tag (git verify-tag / merge.verifySignatures) or a pinned/known-good commit SHA after pull, gating the build/install/skill-sync stages. Treat the existing syntax parse as a bootability check, not a trust control.
2. Make OFFICIAL_REPO_URLS a gate, not just a warning — refuse (or require --force) when origin isn't official; surface the warning in gateway/non-interactive mode too.
3. (Smaller, optional) an owner-only confirmation for the remotely-triggered /update (_handle_update_command / _UPDATE_ALLOWED_PLATFORMS in gateway/run.py). Per §2.6 "authorized callers are equally trusted," so this is friction on a destructive build-and-restart, not a boundary claim.

Acknowledged

This isn't asking the agent process to become a boundary — it's asking the update mechanism to gain a trust anchor before it executes freshly-pulled code, consistent with §4's existing supply-chain guards. The OS-isolation posture still provides the boundary; this just narrows the "build & run whatever origin resolved to" window.