[sftimeless]

Draft: the TSA CRL refresh commit still has to land. Don't merge before then.

What 3.32.1 ships

1. CLI flag-position routing (fix(cli): route on the first positional argument so flags can precede the file #125, already on main as 143aa4d). keel-verify --json BUNDLE.json and keel-verify --json export BUNDLE.json now verify the bundle instead of failing, and export given a work-chain pack verifies it as one. Verdicts, claims and cryptographic checks are unchanged.
2. DigiCert CRL refresh (to be added, see below). It moves coverage forward before the CI guard trips.

Why the CRLs aren't refreshed yet

A dry run of scripts/refresh_tsa_trust_bundle.py at 2026-11-10 06:58Z fetched CRLs byte-identical in validity to what 3.32.0 ships:

CRL	last_update	next_update
DigiCert TimeStamping CA1	11-04 16:40:26Z	11-25 16:40:26Z
DigiCert Assured ID Root	11-05 23:47:20Z	11-26 23:47:20Z
DigiCert Trusted Root G4	11-06 17:42:35Z	11-27 17:42:35Z
GlobalSign (3)	—	2027-01-15

Coverage runs from the latest last_update to the earliest next_update. DigiCert reissues each CRL weekly: CA1 on Wednesday 16:40:26Z, Assured ID on Thursday 23:47:20Z and Root G4 on Friday 17:42:35Z, each valid 21 days. A refresh is only worth doing after Fri 2026-11-13 17:42:35Z, which gives:

• Coverage 2026-11-13T17:42:35Z → 2026-12-02T16:40:26Z (today: → 11-25)
• CI freshness guard trips 2026-11-25T16:40:26Z (today: 11-18T16:40:26Z)

Refreshing on Wednesday would move the end only to 11-26T23:47Z.

⚠️ Don't use the bot branch chore/tsa-trust-refresh (490206d, 11-10 05:28Z). It is based on an old main, and its diff against current main deletes presentation registry v24 and the 3.32.0 bump. Its CRLs are also the same as today's.

Remaining steps (after Fri 11-13 17:42:35Z)

1. On this branch, run python scripts/refresh_tsa_trust_bundle.py. It rewrites the CRL PEMs, the bundle, TSA_TRUST_BUNDLE_V1_HASH and the coupled receipt fixture.
2. Regenerate the manifest: scripts/generate_release_manifest.py embedded --tag v3.32.1.
3. Add the TSA window to the 3.32.1 CHANGELOG entry, including the new stranded window. DigiCert genTime from 11-06T17:42:35Z to before 11-13T17:42:35Z verifies under 3.32.0 and 3.30.1 but not under 3.32.1.
4. Run the full suite with KEEL_OPENSSL_BIN set to OpenSSL 3 and KEEL_TSA_REQUIRE_OPENSSL3=1. Mark the PR ready, merge, and push tag v3.32.1 before 2026-11-18T16:40:26Z, when CI goes red.
5. Repin keel-api (in keelapi/keel-api#838 if it isn't merged yet, otherwise a follow-up PR) and deploy before 2026-11-25T16:40:26Z. From then, production on 3.30.1 or 3.32.0 reports new DigiCert receipts as not_validated_revocation_snapshot_stale.

This commit (c9384ac)

The release prep, in the same 6 files as 3.31.0 and 3.32.0:

• version 3.32.1 in __init__, pyproject and capability/v1.json;
• self-check guards moved forward;
• embedded manifest regenerated for v3.32.1;
• the CHANGELOG entry for the CLI fix.

Checks (local, Python 3.12, OpenSSL 3.6.5, KEEL_TSA_REQUIRE_OPENSSL3=1, keel-permit f0af322)

• ruff check . passes.
• Historical compatibility gate passes (8 cases, 7 categories).
• TSA freshness guard passes; it trips 11-18T16:40:26Z.
• Full suite: 1659 passed, 8 skipped.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn