Repository navigation
High-severity Dependabot alert on transitive cryptography has no PR — grouped weekly config may starve security updates #334
Description
Activity
Root cause found — and it is broader than this alert
I filed this with two candidate causes and no decision. Both are now settled, and the real answer was neither.
Cause 2 (transitive bumps unreachable) — falsified
$ uv lock --dry-run --upgrade-package cryptography Resolved 92 packages in 284ms Update cryptography v48.0.1 -> v50.0.0Nothing blocks the resolution.
cryptographyis transitive-only (required byauthlib,joserfc,pyjwt,secretstorage; absent frompyproject.toml), but no constraint pins it below 50.And Dependabot has already done exactly this bump in this repo: #137, "bump cryptography from 46.0.5 to 46.0.7", changed only
uv.lock(+45/-45) — transitive then too. So transitive updates throughuv.lockare demonstrably within its reach.Cause 1 (the limit starves it) — also not it
automated-security-fixesisenabled=true, paused=false, and vulnerability alerts are on. Per GitHub's docs, security updates are not subject toopen-pull-requests-limitanyway.The actual difference: major vs patch
#137 was
46.0.5 -> 46.0.7, a patch. This alert needs48.0.1 -> 50.0.0, a major. And the only group in thepipblock claims every dependency while permitting only two update types:groups: python-all: patterns: - "*" # claims every dependency update-types: - "minor" - "patch" # ...but never major
No
ignoreentry coverscryptography, and no major bump appears anywhere in the sampled Dependabot history for this repo — only minor/patch (joserfcx2,pyjwt,mcp). Consistent with a structural exclusion rather than a one-off.This is not just
cryptography— two ecosystems are affectedecosystem group patterns update-types pippython-all*minor, patch only npm(/site)site-all*minor, patch only github-actionsactions-all*all types dockerdocker-all*all types So neither the Python dependencies nor the Astro site can receive a major bump via Dependabot at all — security or routine.
github-actionsanddockerare fine. That is the bug; this alert is a symptom of it.Proposed fix
Add
"version-update:semver-major"topython-allandsite-all. Keeping majors inside the group is preferable to letting them flow ungrouped, becauseopen-pull-requests-limit: 1would then fight them — and the config's stated rationale is explicitly to avoid the "20 stale Dependabot PRs" pattern. A grouped major is still a reviewable single PR, which is what the comment in the file asks for.The
mcpmajor-versionignorestays as-is — that one is deliberate and documented (_compat.pypatches mcp internals). Worth noting while here: that ignore block still cites upstream #2610, which is no longer the tracker for the shim (see #127 and #336) — the pin comment deserves the same correction.Then refresh the lock to clear this alert:
uv lock --upgrade-package cryptography # 48.0.1 -> 50.0.0Honest limit of this analysis
I cannot observe Dependabot's internal decision for a security update from outside, so I cannot prove the group filter is what suppressed this specific PR rather than something else in the security path. But a
*-pattern group that permits only minor/patch is wrong on its own terms regardless of the security question, and fixing it is cheap — so the fix is worth making whether or not it fully explains this alert. If a security PR still fails to appear after the config change, the remaining suspect is the security-update path itself and that needs GitHub support rather than more local inspection.Actual exposure remains low: hive never decrypts PKCS#7 EnvelopedData, so the vulnerable path is unreachable. The pipeline gap is the thing worth fixing.
What
There is an open high-severity Dependabot alert with no corresponding pull request:
cryptography>= 44.0.0, < 50.0.0-> patched in50.0.0uv.lockat 48.0.1Surfaced as a push warning ("GitHub found 1 vulnerability on hive's default branch (1 high)"), which is easy to scroll past.
Actual exposure: low, but that is not the point
cryptographyis transitive, not a direct dependency:fastmcp->authlib->cryptography. Hive does not decrypt PKCS#7 EnvelopedData anywhere, so the vulnerable code path is not reached. The bump is hygiene, not an incident.The real finding is the gap in the update pipeline, which will bite on an alert that does matter.
Suspected cause
.github/dependabot.ymlconfigures thepipecosystem as a single weekly grouped PR withopen-pull-requests-limit: 1. Two candidate explanations, both worth confirming:open-pull-requests-limitin ways that can starve the latter.cryptographyappears inuv.lockonly as a dependency ofauthlib. If Dependabot will not lift a transitive pin in the lock without a corresponding manifest entry, no configuration change will produce this PR and the fix has to come viafastmcp/authlib— meaning we need a different mechanism (or an explicit floor inpyproject.toml) to respond to transitive advisories at all.What to do
pyproject.tomlwhen an advisory lands, or document that transitive alerts are triaged manually and how.cryptography >= 50.0.0in the lock).Why file rather than just bump
A one-off
uv lock --upgrade-package cryptographycloses this alert and leaves the pipeline gap intact. The next transitive high-severity advisory would be equally silent, and the only reason this one was noticed is that someone happened to read a push warning.Related: #126 (added the Dependabot config), ADR referenced pin policy for
mcpin the same file.