12 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
the_og	26c66b7db1	Merge branch 'main' into fix/68-console-gate	2026-07-12 21:28:27 -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
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
AJ Avezzano	6f03b50a43	ci: disable generate_release_notes (unsupported on Gitea)	2026-06-29 20:38:00 -04:00
AJ Avezzano	335a26a2d6	Fix CI: platform-specific Python setup and artifact actions v3 for Gitea ... - Use actions/setup-python only on Linux (container); macOS/Windows create a venv from pre-installed python3.12 to avoid privileged install failures - Downgrade upload/download-artifact to v3 (v4 uses an API Gitea doesn't support) - Remove merge-multiple (v4-only option) from download-artifact - Change release files glob to artifacts/**/* (v3 nests each artifact in a subdir) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-06-29 19:14:28 -04:00
AJ Avezzano	dd7557ea62	Add cross-platform packaging, icons, and Claude Code config discovery ... - Auto-discovers Claude Code (~/.claude/settings.json) alongside Claude Desktop - Generated icons/app.icns (macOS) and icons/app.ico (Windows) from rounded PNGs - bcc.spec: PyInstaller spec for all platforms (.app on macOS, onefile on Windows/Linux) - .github/workflows/release.yml: builds and publishes GitHub Release on version tags - scripts/build_icons.py: regenerates icon files from source PNGs - requirements-dev.txt: adds pyinstaller and pillow for building - CLAUDE.md: initial repo guidance for Claude Code Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-06-29 15:01:30 -04:00