7 Commits

Author	SHA1	Message	Date
BCC Agent	4836c6cb48	chore(#68): rotate signing keys, key-rotation re-attestation mode, harden show-seed-b64 ... Wires the maintainer's freshly-rotated signing keys into BCC (issue #68 finding 5: the old key was shared between catalog+release and had been exposed to CI), adds a key-rotation re-attestation mode to the Catalog Console so the Console can actually re-sign under the new key, and hardens the show-seed-b64 CLI prompt that led to a private key being pasted into a chat. ## New keys (#68 finding 5) - bcc_core.CATALOG_PUBKEYS -> new CATALOG pubkey (0s24PmkZcTT5yxNDdyTPHl5fyxArrHNPJKBjnXoQd8k=). Signs data/catalog.json, Console-only, offline. - .github/workflows/ci.yml EXPECTED_CATALOG_PUBKEY_B64 -> same new catalog pubkey (the CI trust anchor added for #68 finding 4). - scripts/sign_checksums.py RELEASE_PUBKEYS -> new RELEASE pubkey (6BnPgJEHJFyVltFoLTCNadIsehjy00iiW8IRlC1TfhA=). Signs SHA256SUMS only, CI-resident. - README.md 'Verifying your download' / 'Signing keys' sections filled in with both pubkeys, explicit about which key is which. The old key 082NOwVB7uURkvfyS3+knJ+40Fk6C9unsF47+2uPKo4= is retired (it was shared and exposed to CI) and is deliberately NOT retained in either trust list -- keeping a burned key in CATALOG_PUBKEYS would defeat the point of rotating it. ## Key-rotation re-attestation mode (Catalog Console) Problem: after the key swap, the existing data/catalog.json.sig (signed with the OLD key) no longer verifies under the NEW CATALOG_PUBKEYS, but catalog content is unchanged, so diff_catalogs(last_signed, current) is empty -- and can_sign()'s empty-diff guard (load-bearing, #68 finding 1) correctly refuses to sign an empty changeset. Without a rotation-aware path, the Console could never re-sign and CI would stay red forever. Fix: treat rotation as a full re-attestation, not a diff. - catalog_review.py: ReviewSession/start_review gain reattest: bool = False. When set, changes is built via diff_catalogs(None, new_catalog) -- every entry presented as if newly added, requiring a fresh acknowledgement -- instead of diffing against old_catalog. can_sign() is UNCHANGED: it still refuses a genuinely-empty changeset and still enforces the TOCTOU blob-SHA pin and the blocking-risk check, because reattest sessions simply never produce an empty changeset (unless the catalog itself is empty). - catalog_console.py: adds catalog_signature_valid_at(repo_dir, commit, raw), which calls bcc_core.verify_catalog_signature directly (never reimplemented) to detect whether the committed .sig verifies under the CURRENT CATALOG_PUBKEYS. ReviewWindow._on_load's source=main path uses this to decide reattest=True/False, and shows a loud, explicit red banner ("KEY ROTATION IN PROGRESS...") whenever reattest mode is entered -- never silent. Status text and Sign-button gating flow through the same can_sign()/all_entries_acknowledged() path as normal review. - tests/test_catalog_review.py: 6 new tests covering re-attest mode (one change-entry per server, gating until all acknowledged, then permits), confirming normal mode still refuses an empty diff (rotation path is not a general bypass), and confirming reattest mode still enforces the blocking-risk check and the TOCTOU pin. ## show-seed-b64 hardening (Task 3) The maintainer ran show-seed-b64 --release, saw an ambiguous prompt, and pasted the printed PRIVATE seed into a chat believing it was public. - cmd_show_seed_b64: passphrase prompt is now explicit ("Passphrase for the release signing key (the one YOU chose when generating it)"). A loud three-line warning banner prints to STDERR immediately before the seed ("!!! PRIVATE KEY BELOW..."); the seed itself stays alone on STDOUT so piping into pbcopy or a CI secret field still works cleanly. - cmd_keygen: labels for both key kinds now say PUBLIC/PRIVATE explicitly and state safety properties inline (safe to commit vs. never commit), so the printed output can't be mistaken for the other key's. ## Verification - ruff check . / ruff format --check .: clean. - pytest: full suite green (360 passed, 1 skipped). - Delete-the-check-and-watch-it-fail: each of can_sign()'s four gates (empty-diff, TOCTOU pin, blocking-risk, acknowledge-all) and the reattest branch itself were individually removed and confirmed to turn a test red, then restored -- see PR description for the exact failures. Not touched: data/catalog.json (content-signed, maintainer's job via the Console). No private key generated, requested, or committed. bcc.py untouched (open PR #67).	2026-07-13 12:24:28 -04:00
BCC Agent	38f14deeff	fix(core): validate config.env, enforce version pinning, fix CI trust anchor and resolve_catalog guards (#68) ... Fixes findings 2, 3, 4, 6, 7 from the issue #68 adversarial review. - Finding 2: config.env was type-checked only. Add CATALOG_DENIED_ENV_KEYS (case-insensitive) for interpreter/loader-override keys (NODE_OPTIONS, PYTHONPATH, LD_PRELOAD, ...), apply the ASCII check and the existing secret-value check to env keys/values, and require env values to be empty or a single <PLACEHOLDER> token. - Finding 3: version pinning was only checked by catalog_review.py (which never runs on the signing path per finding 1). Move enforcement into _validate_catalog_config: npm/uvx specs must carry @version or ==version (scoped names handled), docker images must have an explicit non-latest tag. Only the first plausible package-spec token is checked, so flags, <PLACEHOLDER>s, and docker subcommands/flags don't trip it. All 19 real catalog entries still validate clean. - Finding 4: the CI catalog-signature gate imported bcc_core from the PR branch and trusted whatever CATALOG_PUBKEYS said there, so a PR changing both catalog.json and CATALOG_PUBKEYS (with a matching signature) went green. ci.yml now hardcodes the expected base64 pubkey and asserts bcc_core.CATALOG_PUBKEYS matches it before verifying the signature. NOTE: the maintainer is planning to rotate this key -- update EXPECTED_CATALOG_PUBKEY_B64 in ci.yml as its own reviewed change when that happens, never bundled with a catalog content change. - Finding 6: resolve_catalog's anti-rollback/anti-freeze guards sat behind `if best_version >= 0`, so the first verified candidate was accepted unconditionally and the anti-freeze anchor drifted with each accepted candidate instead of staying fixed. The cap is now measured against the bundled catalog's version specifically (the trust anchor baked into the binary), regardless of evaluation order; bundled wins version ties; and a new pure `floor` parameter lets a future caller pass a persisted accepted-version floor. - Finding 7: catalog id is now constrained to ^[a-z0-9][a-z0-9._-]{0,63}$. Tests: fixed _minimal_catalog to use a pinned package (was enshrining finding 3), rewrote the env-passthrough test to prove the validation boundary instead of asserting env passes through unchecked, and reordered test_resolve_catalog_rejects_absurd_version_jump so it actually exercises the first-candidate path. Added positive/negative tests for every new rule. Manually verified each new check by commenting it out and confirming the guarding test goes red, then restoring it.	2026-07-12 21:27:08 -04:00
the_og	6fce19cc67	ci: gate the catalog signature, smoke-test the release key (#61, #63) ... 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.	2026-07-12 18:30:30 -04:00
BCC Agent	cd38fd0c78	Sign release checksums with Ed25519 (#63) ... Publish SHA256SUMS for every release archive and sign it with a detached Ed25519 signature (SHA256SUMS.sig), since paid code signing (macOS Developer ID, Windows Authenticode) and Sigstore keyless (needs a Fulcio-trusted OIDC issuer; self-hosted Gitea isn't one) are both out of budget/scope. - scripts/sign_checksums.py: dependency-light (cryptography only) helper to hash a directory of files into a sha256sum(1)-compatible SHA256SUMS manifest, sign it (domain-separated: b"bcc-release-v1|" + raw manifest bytes), and verify a signature. CLI has generate/ sign/verify subcommands; verify doubles as the check path. - tests/test_checksums.py: 15 unit + CLI-subprocess tests covering hashing, manifest formatting, sign/verify roundtrip, tamper detection, wrong-key rejection, domain-separation, and the no-key-provided failure path (must error, never write an empty/ bogus .sig). - .github/workflows/release.yml: Publish Release job now checks out the repo, flattens build artifacts, generates SHA256SUMS, and signs it from the RELEASE_SIGNING_KEY secret (base64 raw Ed25519 seed) if present. If the secret is absent, the release still publishes with a loud ::warning:: and no .sig — it never fails the release or publishes a bogus signature. - README.md: new 'Verifying your download' section with the (still placeholder) public key, sha256sum -c / Get-FileHash commands, and an explicit statement that this does not remove Gatekeeper/ SmartScreen warnings. - requirements-dev.txt / ci.yml: add cryptography as a dev/test dependency for the new script and its tests. Touches no files from bcc_core.py / tests/test_core.py / pyproject.toml / bcc.spec to avoid colliding with concurrent work on those files.	2026-07-12 17:30:09 -04:00
Cowork Supervisor	62c8a2ea65	ci: use host py launcher for Windows tests (runner blocks setup-python) ... The self-hosted Windows runner's PowerShell execution policy rejects setup-python's install script, so Windows mirrors release.yml: py -3.12 + venv (the version the release binaries ship with). Linux keeps the full 3.10/3.12/3.13 setup-python matrix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-12 13:02:09 -04:00
Cowork Supervisor	42963f98b4	ci: test on windows + python 3.13 (#40) ... Closes #40 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-12 12:47:14 -04:00
AJ	8124150e34	ci: add lint + test workflow (ruff check/format, pytest on py3.10 & 3.12)	2026-07-01 23:43:30 -04:00