5 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
BCC Agent	aa40f8e139	feat(catalog-console): a keys status command, and complete rotation without a red main (#62, #68) ... Two problems from issue #68's follow-up review: 1. The maintainer -- the only person who will ever use this tool -- cannot reliably tell which of the two signing keys is which or what state either is in. He already pasted a private key into a chat window because a prompt was ambiguous. That's a defect in this tool, not user error. 2. PR #71 rotates bcc_core.CATALOG_PUBKEYS, which makes data/catalog.json.sig (signed by the retired key) stop verifying and the CI catalog-signature job go red. The Console could previously only load/sign against `main`, so the only way through was to merge a red PR and fix main afterwards -- normalizing exactly the alarm fatigue this whole design exists to prevent. Task 1 -- `python catalog_console.py keys`: A plain-English-first status report for BOTH keys: purpose, where the private half lives, whether it exists locally, its fingerprint, whether that fingerprint matches every place its public half is expected to be committed (bcc_core.CATALOG_PUBKEYS, ci.yml's trust anchor, and scripts/sign_checksums.RELEASE_PUBKEYS -- checked independently, since issue #68 finding 4 was exactly bcc_core.py and ci.yml silently drifting apart), and whether data/catalog.json.sig currently verifies -- ending with the exact command to run next. Needs no passphrase and never touches private key bytes: a plaintext public-key cache (store_public_key/load_public_key) is written alongside the existing encrypted private blob at keygen time, precisely so this command can report a fingerprint without decrypting anything. The status/report logic (key_status, render_key_status_report, recommend_next_steps, fingerprint_pubkey, extract_pubkey_list_literal, extract_ci_trust_anchor_pubkey) is pure and lives in catalog_review.py; cmd_keys in catalog_console.py is a thin printer over it, per the project's existing pure-core/thin-GUI split. Task 2 -- rotation completable without a red main: ReviewWindow now offers a "current branch" source (auto-detected via `current_branch()`, or --ref to name one explicitly) alongside "main" and open PRs. Loading it runs the exact same diff-against-last-signed / rotation-detection logic "main" always used (_load_own_ref, extracted from the old hardcoded-to-main _on_load), just parameterized on the ref. Signing now pushes to session.loaded_ref, never a hardcoded "main" (commit_and_push_signed_catalog's branch param was already there -- only the call site was wrong). The ref-list computation itself is a pure function (compute_own_refs) so this seam is unit-testable without git or Qt. None of can_sign()'s guards (empty-diff, acknowledge-all, blocking-risk, TOCTOU) were touched. This lets a rotation branch be reviewed, re-attested (every entry, since the new key never vouched for any of them -- issue #68 finding 5 follow-up), signed, and pushed to ITS OWN branch before it's ever merged. Task 3 -- label the keys everywhere: PassphraseDialog now shows which key (CATALOG vs RELEASE) and its fingerprint before the passphrase field, both in its window title and its prompt text -- the exact ambiguity that led to a private key being pasted into a chat window. cmd_keygen's stored-key confirmation now reads "CATALOG private key encrypted..." / "RELEASE private key encrypted..." instead of a capitalized-lowercase kind. The reattest banner now says "CATALOG signing key" / "CATALOG key" throughout instead of "the key". PySide6's import is now guarded (try/except -> _PYSIDE6_AVAILABLE) and every GUI class definition that depends on it moved under `if _PYSIDE6_AVAILABLE:`. `keygen`, `show-seed-b64`, and the new `keys` command have no GUI dependency and now work (and are testable) in an environment without PySide6 -- which is exactly this repo's own `test` CI job (pytest + cryptography only, no PySide6). `gui` fails with a clear message instead of an ImportError stack trace if it's missing. Tests: 26 new pure-function tests in tests/test_catalog_review.py (fingerprint_pubkey, extract_pubkey_list_literal, extract_ci_trust_anchor_pubkey, key_status, recommend_next_steps, render_key_status_report) and a new tests/test_catalog_console_git.py (14 tests) covering compute_own_refs, current_branch, commit_and_push_signed_catalog's branch targeting, and catalog_sig_status_on_disk against real local git repos -- importing catalog_console.py directly, proving it works without PySide6. 400 passed, 1 skipped (pre-existing). ruff check / ruff format --check clean.	2026-07-13 13:10:36 -04:00
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
BCC Fix Agent	82483e693d	fix(catalog-console): close the vacuous review gate; split catalog/release signing keys ... Fixes #68 findings 1 and 5. Finding 1 -- the review gate signed without reviewing anything: - ReviewWindow._on_sign hardcoded "main" as the TOCTOU comparison ref, so any PR review (where _on_load pins the PR head's blob SHA) could never sign; the only working path was main-vs-itself, whose empty diff made can_sign() vacuously True (set() <= set()). Commit b08cf21 signed 19 entries through exactly that path with zero of them reviewed. - can_sign() now refuses an empty changeset outright, and itself checks has_blocking_risk() across every changed entry rather than trusting the GUI to have disabled a checkbox. - ReviewSession now carries loaded_ref (the exact ref reviewed); a new pure sign_precondition(session, resolve_blob_sha) resolves the TOCTOU SHA from that ref, never a hardcoded "main". _on_load's retry path re-diffs instead of re-pinning the same stale SHA, so a blob-mismatch refusal can't loop forever. - source="main" now diffs against the last catalog a maintainer actually SIGNED (walking catalog.json's git history until a version verifies against the current .sig), not against itself. - Replaced the theatre-only test_no_acknowledge_all_function_exists (only asserted no function was *named* acknowledge_all) with a test that also exercises the real gate. Added can_sign/sign_precondition coverage for the empty-diff, blocking-risk, and ref-resolution seams -- each verified to fail when its guard is removed. Finding 5 -- the catalog key and release key were the same CI-resident key: - scripts/sign_checksums.py gets its own RELEASE_PUBKEYS (separate from bcc_core.CATALOG_PUBKEYS) and a verify_checksums_against_any() helper. - release.yml's signing-smoke-test now verifies RELEASE_SIGNING_KEY against RELEASE_PUBKEYS only -- it no longer imports bcc_core/CATALOG_PUBKEYS at all, so this workflow can never compare a CI secret against the catalog's root of trust. - catalog_console.py: keygen/show-seed-b64 gain --release, with separate keychain/file storage per key kind. show-seed-b64 refuses to run without --release, so the catalog seed can't be exported to a CI secret by habit. - README documents both keys' trust properties and the asymmetry: a CI compromise burns the release key, never the catalog key. The maintainer must rotate the catalog key (it was CI-resident, so treat it as burned for catalog use) and generate a fresh release key -- see the PR description for the exact steps. No key is generated or committed here.	2026-07-12 21:25:34 -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