Fix dependency CVEs; raise Python floor back to 3.10 - #5
Open
goetchstone wants to merge 1 commit into
Open
Conversation
pip-audit found real CVEs in the shipped runtime, and traced the worst of them to my own earlier decision to support Python 3.9. The 3.9 floor was a mistake. Every patched `starlette` and `python-multipart` release requires >=3.10; the newest 3.9-compatible versions are starlette 0.49.3 (5 advisories) and python-multipart 0.0.20 (6 advisories) — and python-multipart parses every form POST this app serves. Supporting 3.9 meant shipping a web app on knowingly-vulnerable request-handling libraries. It was also unnecessary: scripts/build_app.sh bundles its own CPython 3.12, so the supported install never needed the system interpreter. - requires-python back to >=3.10, with a comment explaining it is a SECURITY floor so nobody "helpfully" lowers it again. ruff target-version to py310. - Explicit security floors on the deps that parse/transport untrusted input: python-multipart>=0.0.31, starlette>=1.3.1, cryptography>=50.0.0, h2>=4.4.1. - Upgraded the bundled runtime (cryptography 49->50, h2 4.3->4.4.1). Both the dev environment and the shipped bundle now audit clean. - Dev venv rebuilt on 3.12 so tests run against the patched stack rather than 3.9's frozen, vulnerable resolution. Suite still 124 green on starlette 1.6 / fastapi 0.141. Automation so this doesn't recur: - .github/dependabot.yml — weekly pip + github-actions update PRs. Dependabot *security* updates were already enabled, but with no config there were no routine version bumps. - CI gains ruff, bandit, and a separate `audit` job running `pip-audit --strict`, so a newly-disclosed CVE fails the build even when nothing in the repo changed. Also verified (public repo): no .pem/.p8/config.json/token file has ever been committed, and the only "PRIVATE KEY" matches in history are form placeholders and the PEM-header normalizer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pip-auditfound real CVEs in the shipped runtime — and traced the worst of them tomy own earlier decision to support Python 3.9.
The 3.9 floor was a mistake
Every patched
starletteandpython-multipartrelease requires >=3.10. Thenewest 3.9-compatible versions are
starlette 0.49.3(5 advisories) andpython-multipart 0.0.20(6 advisories) — and python-multipart parses every formPOST this app serves. Supporting 3.9 meant shipping a credential-handling web app on
knowingly-vulnerable request-handling libraries.
It was also unnecessary:
scripts/build_app.shbundles its own CPython 3.12, so thesupported install never needed the macOS system interpreter.
Changes
requires-pythonback to >=3.10, with a comment stating it's a security floorso it doesn't get "helpfully" lowered again.
ruff target-version→py310.python-multipart>=0.0.31,starlette>=1.3.1,cryptography>=50.0.0,h2>=4.4.1.cryptography49→50,h24.3→4.4.1).frozen, vulnerable resolution.
Both the dev environment and the shipped bundle now audit clean. Suite still
124 green on starlette 1.6 / fastapi 0.141 (a major-version jump, so this was a
genuine regression check, not a formality).
Automation, so it doesn't recur
.github/dependabot.yml— weeklypip+github-actionsupdate PRs. Dependabotsecurity updates were already enabled on the repo, but with no config there were no
routine version bumps, so a dependency could sit on a vulnerable-but-unadvised
release indefinitely.
ruff,bandit, and a separateauditjob runningpip-audit --strict— a newly-disclosed CVE now fails the build even when nothing in the repo changed.
Secret check (public repo)
Verified no
.pem/.p8/config.json/ token file has ever been committed. Theonly
PRIVATE KEYmatches in history are form placeholders and the PEM-headernormalizer in
config.py. Secret scanning + push protection are on.🤖 Generated with Claude Code