Security Release Process
What you'll find here
The same package gates as a normal release, with private coordination before disclosure. Use this when responding to a vulnerability report or any security-sensitive fix.
Patch first, disclose second.
No exploit details in public issues, PR titles, changelog drafts, or generated docs until patched artifacts are available.
Security Patch Flow
- Triage the report privately and record the impacted versions.
- Open a private fix branch or security advisory branch.
- Add regression tests that fail without the fix.
- Run quality, package, docs, and security checks.
- Publish the smallest viable
0.x.ypatch release. - Publish advisory details after patched artifacts are available.
Private Coordination
No public exploit details before patched packages are available.
Use GitHub Security Advisories or a private maintainer channel for coordination. Avoid leaking impacted-version detail in public-facing PR titles or commit messages.
Release notes
Security release notes must state:
Affected versions
Fixed version
Severity and impact
In user terms — not internal jargon.
Mitigation
For users who cannot upgrade immediately.
Exposure scope
Whether secrets · receipts · local state · provider calls · or memory writes may have been exposed.
Disclosure
Disclosure happens only after every gate below is green.
- The patch release is published to PyPI.
- GitHub release notes are live.
- The changelog is updated.
- Any required advisory or CVE entry is ready.
Post-Release Verification
- Install the patched package from PyPI in a clean environment.
- Run the relevant regression tests or smoke workflow.
- Confirm that docs and release notes point to the fixed version.
- Verify the signed tag with
git tag -v vX.Y.Z. - Confirm the GitHub Release includes
craik-release-signing-key.ascand that its fingerprint matches the tag-signing key.