6fce19cc67
CI / Tests (py3.10 / ubuntu-latest) (push) Successful in 10s
CI / Tests (py3.12 / ubuntu-latest) (push) Successful in 10s
CI / Lint (ruff) (push) Successful in 6s
CI / Tests (py3.12 / windows-latest) (push) Successful in 23s
CI / Tests (py3.13 / ubuntu-latest) (push) Successful in 10s
CI / Catalog signature (push) Successful in 6s
Two gaps closed now that a real key exists. 1. CI 'Catalog signature' job (the #61 gate): every push/PR verifies data/catalog.json against data/catalog.json.sig using the public key in bcc_core, and runs validate_catalog. The threat model here is not an outsider pushing to the repo -- it is merging a friendly-looking PR without really reading it. A contributor can change catalog.json but cannot produce a matching signature, so a blindly-merged PR now lands as a red build within a minute instead of quietly riding into the next release. Public-key only; no secret involved. 2. release.yml 'Signing key smoke test' (workflow_dispatch only): the Publish job is gated on a tag, so a manual run never exercised signing -- a wrong or missing RELEASE_SIGNING_KEY would first surface during a real release. This signs a throwaway manifest with the secret and verifies it against the public key compiled into bcc_core, proving the two halves of the keypair actually match. Publishes nothing.