Skip to content

CI checks, CVE monitoring, release gating, and automated security patch releases - #2

Merged
jgoodloe merged 3 commits into
mainfrom
claude/first-release-bg8n84
Nov 8, 2026
Merged

jgoodloe merged 3 commits into
mainfrom
claude/first-release-bg8n84

Conversation

@jgoodloe

@jgoodloe jgoodloe commented Nov 8, 2026

Copy link
Copy Markdown
Owner

Summary

Adds continuous build verification, CVE monitoring, release gating, and automatic security patch releases.

Key changes

CI (.github/workflows/ci.yml)

  • Smoke test on Python 3.10 / 3.12 / 3.14 (scripts/smoke_test.py): byte-compiles every file, imports every module (including the GUI app when tkinter is available), verifies the sample CA → leaf chain signature, and round-trips a DER OCSP request.
  • CVE audit: pip-audit scan of requirements.txt as it resolves for a fresh install.
  • Runs on every push/PR to main and weekly on a schedule; a scheduled failure opens an issue assigned to the repository owner.

Release gating (.github/workflows/release.yml)

  • Every release trigger now runs the full CI suite first and publishes only if all checks pass.
  • On failure, no release is created; an issue assigned to the owner explains the failure and the options. A skip_checks input on manual dispatch lets a human explicitly override after review.

Security autopatch (.github/workflows/security-autopatch.yml, scripts/security_autopatch.py)

  • Daily audit of the dependency ranges. When a published vulnerability has a fix outside the allowed range, the workflow raises the range, re-installs, re-audits, runs the smoke test, and — only when everything passes — commits the bump and publishes the next patch release automatically, with an informational issue assigned to the owner.
  • If verification fails, or an advisory has no published fix, nothing is committed or released; an assigned issue asks for a human decision.
  • The range-rewriting logic was validated against real data: run against the old cryptography>=42,<44 pin it reproduces the manual v1.0.1 fix (>=49.0.0,<51.0.0) exactly.

Housekeeping

  • Dependabot config: weekly update PRs for pip dependencies and GitHub Actions.
  • .gitignore for Python bytecode caches; removed the __pycache__/*.pyc file that was tracked in git.

Verification

  • Smoke test passes locally on cryptography 50.0.2 (all modules, both crypto paths).
  • pip-audit -r requirements.txt returns clean.
  • All workflow YAML parses; autopatch script tested on both vulnerable and clean requirements.

Generated by Claude Code

Add a CI workflow that runs on every push and pull request to main:
a smoke test (byte-compile, import every module, exercise the sample
certificate chain and OCSP request paths) across Python 3.10/3.12/3.14,
plus a pip-audit scan of requirements.txt for known CVEs. The same
workflow runs on a weekly schedule and opens an issue assigned to the
repository owner when it fails, so new advisories surface without
anyone watching.

Gate releases on those checks: the release workflow now calls CI first
and only publishes when everything passes. On failure no release is
created; instead an issue is opened and assigned to the owner, who can
fix the problem and re-trigger, or consciously override with the new
skip_checks input on a manual run.

Add Dependabot config for weekly pip and github-actions update PRs, and
a .gitignore for Python bytecode caches (removing the tracked .pyc).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0126cb3H46h57uDx2NmeV6b2
Add a daily security-autopatch workflow: it audits requirements.txt,
and when a published vulnerability has a fix outside the allowed
version range, it raises the range, re-installs, re-audits, and runs
the smoke test. Only if every check passes does it commit the bump and
publish a patch release automatically, with an informational issue
assigned to the owner. If checks fail, or an advisory has no published
fix, nothing is committed or released - an issue assigned to the owner
asks for a decision instead, matching the release-gating policy.

The range-rewriting logic reproduces the manual v1.0.1 fix exactly when
run against the old vulnerable pin (verified locally), and leaves a
clean requirements file untouched.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0126cb3H46h57uDx2NmeV6b2
Python 3.12 rejects class instances as dataclass defaults (ValueError:
mutable default ... use default_factory), so importing the app failed on
3.12 and 3.14 - caught by the new CI smoke test on its first run. Use
field(default_factory=hashes.SHA1), which behaves identically on all
supported versions and avoids sharing one hash instance across specs.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0126cb3H46h57uDx2NmeV6b2
@jgoodloe
jgoodloe merged commit 52ce4ba into main Nov 8, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants