fix(server): bump cryptography 48.0.1 → 50.0.0 to clear two HIGH CVEs - #83
Conversation
The Trivy image scan fails on cryptography 48.0.1 (transitive via authlib, via fastmcp) with two HIGH findings: CVE-2026-69247 (GHSA-g6cj-pr64-35w5, fixed in 50.0.0) -- PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing. CVE-2026-69249 (GHSA-jwv3-5hgf-82ww, fixed in 49.0.0) -- duplicate self-signed intermediates can cause exponential path-building. 50.0.0 clears both, but it was published on 2026-07-31 and so falls inside the 7-day exclude-newer cooldown; a plain re-lock cannot reach it. Add a per-package cooldown exemption, the same trade already made for starlette: a known, published HIGH CVE outweighs the marginal supply-chain risk of a 5-day-old release from PyCA. While editing the exemption table, rewrite both cutoffs as explicit UTC timestamps. uv resolves a bare date against the locking machine's local timezone, so `starlette = "2026-06-13"` locked to 22:00Z on a UTC+2 machine and would have silently rewritten to 20:00Z on this UTC+4 one. The starlette value is pinned to the timestamp already in the lock, so its resolution is unchanged. Verified: `trivy fs` on the lock reports the same 2 HIGH findings as CI before the bump and 0 after; 229 server tests pass; registry validate reports all 40 entries valid.
|
Warning Review limit reached
Next review available in: 41 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
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. Comment |
2 participants
Problem
The Trivy image scan fails on
cryptography 48.0.1(transitive:fastmcp→authlib→cryptography) with two HIGH findings. Seen on PR #79'sscanjob, but it is not specific to that branch —mainlocks the same version, so every image scan fails until this lands.GHSA-g6cj-pr64-35w5EnvelopedDatadecryption exposes a Bleichenbacher oracle through distinguishable errors and timingGHSA-jwv3-5hgf-82wwFix
Bump
cryptographyto 50.0.0, which clears both.It could not be a lock-only change like c2cc879 (joserfc): 50.0.0 was published 2026-07-31, so it sits inside the 7-day
exclude-newercooldown and a plain re-lock cannot reach it. So this adds a per-package cooldown exemption — the same trade already made forstarlette: a known, published HIGH CVE outweighs the marginal supply-chain risk of a 5-day-old release from PyCA. The cutoff is fixed at2026-08-01T00:00:00Z, so the exemption admits exactly 50.0.0 and does not open the window for later releases.Re-locked with
uv lock --upgrade-package cryptography, so the lock diff is that one package and nothing else.Also in here
The exemption cutoffs are now written as explicit UTC timestamps rather than bare dates. uv resolves a bare date against the locking machine's local timezone, so
starlette = "2026-06-13"locked to2026-06-13T22:00:00Zon the UTC+2 machine that wrote it, and silently re-wrote itself to20:00:00Zwhen I re-locked on a UTC+4 one — lock churn that has nothing to do with the change being made.starlette's value is pinned to the timestamp already in the lock, so its resolution is unchanged; only the spelling is.Verification
trivy fs --scanners vuln --severity CRITICAL,HIGH --ignore-unfixed server/uv.lock— 2 HIGH before (identical to the two CI reports, used as a control that the scan really detects them), 0 after.uv run pytest— 229 passed.uv run python -m awos_recruitment_mcp.validate— all 40 entries valid.The image scan in CI on this PR is the real confirmation; the lock scan above just covers the same package set faster.