fix(signing)!: Ed25519-only registry signing verified against the pinned key

[Patel230]

Summary

Makes the published skill registry's signature mean something. The rolling registry-latest release currently carries an hmac-sha256 signature made with the literal dev-fallback-key from the workflow file, so anyone can forge it. This PR:

• signs registry.json with Ed25519 only (HMAC and SKILLS_SIGNING_KEY removed from tools/sign_manifest.py);
• commits the pinned public key as keys/registry-ed25519.pub (the key Rho pins, spec §1.10);
• makes publish-registry.yml fail when SKILLS_ED25519_PRIVATE_KEY is unset, and verify its own signature with the committed public key before uploading;
• splits the workflow into a secret-free read-only build job and a sign-and-publish job that installs only a hash-locked cryptography stack; pins every action to a commit SHA; adds a non-cancelling concurrency group; validates with the zero-warning budget;
• documents the §6 registry-signature contract in docs/REGISTRY.md.

It also carries the owner's uncommitted work-in-progress fix to the workflow (first commit, unchanged).

Merge note: the SKILLS_ED25519_PRIVATE_KEY secret already exists on this repo (checked with gh api .../actions/secrets: the only secret listed). Merging touches tools/**, so the publish workflow runs on merge and replaces the forgeable asset. If the secret does not correspond to keys/registry-ed25519.pub, the new verify step fails the run before anything is uploaded; that is intended.

Findings addressed

• F101 (critical): forgeable published signature. Reproduced: the published registry-signature.json is hmac-sha256, its sha256 matches the published bytes, and HMAC-SHA256('dev-fallback-key', sha256) equals the published signature. Fixed with Ed25519-only signing, the committed pinned key, fail-if-unset, and verify-before-upload. The new verify --signature-file rejects the currently published asset (algorithm must be 'ed25519', got 'hmac-sha256').
• F248 (high): unpinned actions and pip dependencies in the only job with the key and contents: write. Actions are SHA-pinned; dependencies install from tools/requirements.lock / tools/requirements-sign.lock with --require-hashes --no-deps; the key-holding job installs only cryptography/cffi/pycparser; pip install --upgrade pip is gone; persist-credentials: false. CI now also runs pip-audit on both lock files.
• F109 (publish-registry part): SHA pins, concurrency: {group: publish-registry, cancel-in-progress: false}, --warning-budget, and path triggers for keys/**, manifest-schema.toml and the workflow file. (The ci.yml github.event.before guard is in the companion docs/tooling PR.)
• F115 (part): docs/REGISTRY.md said the registry goes "to the CDN"; it goes to the registry-latest GitHub release.

Not reproduced / deferred

• The signature format is now final for Rho (RH-extensions verifies it). Rho must ship the pinned key before, or together with, the first Ed25519-signed registry it relies on. Old Rho builds do not check signatures at all, so nothing breaks for them.

Verification

Run on this branch (macOS, Python 3.14 venv; CI uses 3.11):

Command	Result
make lint	pass (All checks passed!)
bash scripts/check-consumer-boundaries.sh	pass
python -m compileall -q categories	pass
python tools/validate_skill.py --all --warning-budget tools/validation_warning_budget.json	pass: 14011/14011, budget matches
python tools/update_registry.py && python tools/update_registry.py --check	pass (14011 indexed, current)
python tools/check_version_sync.py	pass
python tools/sync_marketplace.py --check	pass
python tools/check_references.py	pass
python tools/check_self_contained.py	pass
python tools/check_secrets.py --strict	pass
python tools/check_shell_commands.py --strict	pass
python -m pytest tests/ -q --cov --cov-fail-under=88	pass: 417 passed, coverage 89.85%
make package-check	pass
actionlint 1.7.7 .github/workflows/publish-registry.yml	clean. The two SC2086 infos it reports on ci.yml are pre-existing.
pip-audit --require-hashes -r tools/requirements.lock -r tools/requirements-sign.lock	No known vulnerabilities found
pip install --require-hashes --no-deps -r tools/requirements.lock in a clean Python 3.11 venv	installs; pip check clean; validate_skill.py runs

Signing simulation with a throwaway keypair (never the real key): the unset-secret branch exits 1 with the ::error:: message. sign registry.json --ed25519 emits {target: "registry.json", algorithm: "ed25519", sha256 (64 hex, equal to shasum -a 256), signature (128 hex)}. verify --signature-file ... --key keys/registry-ed25519.pub fails for the throwaway signature (as it must) and passes with the throwaway public key. OpenSSL 3.6 pkeyutl -verify -rawin independently verifies the signature over the 64 ASCII hex bytes.

New tests: tests/test_sign_manifest.py covers the contract: ASCII-hex message, tamper cases, pinned-key value, and no private key in keys/. tests/test_workflows.py covers SHA-pinned actions in every workflow, secret scoping, fail-if-unset, the step order sign < verify < upload < publish, hash-locked installs, and lock-file integrity.

Follow-ups

• Rho (RH-extensions) pins the same key and verifies registry-signature.json fail-closed; both sides test with throwaway keys.
• After merge, confirm that the first Publish Skill Registry run on main passes the verify step, and check the new asset: gh release download registry-latest -p registry-signature.json, then jq .algorithm should print "ed25519".
• Consider enabling GitHub private vulnerability reporting (currently disabled) and Dependabot for tools/*.lock.

🤖 Generated with Claude Code