High-severity Dependabot alert on transitive cryptography has no PR — grouped weekly config may starve security updates #334

Activity

1. mlorentedev

   added

   dependenciesPull requests that update a dependency filePull requests that update a dependency file

   choreMaintenance, refactor, cleanup, qualityMaintenance, refactor, cleanup, quality

   on Aug 8, 2026
2. mlorentedev commented on Aug 8, 2026

   

   mlorentedev

   on Aug 8, 2026

   OwnerAuthor

   More actions

   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.0
   

   Nothing blocks the resolution. cryptography is transitive-only (required by authlib, joserfc, pyjwt, secretstorage; absent from pyproject.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 through uv.lock are demonstrably within its reach.

   Cause 1 (the limit starves it) — also not it

   automated-security-fixes is enabled=true, paused=false, and vulnerability alerts are on. Per GitHub's docs, security updates are not subject to open-pull-requests-limit anyway.

   The actual difference: major vs patch

   #137 was 46.0.5 -> 46.0.7, a patch. This alert needs 48.0.1 -> 50.0.0, a major. And the only group in the pip block claims every dependency while permitting only two update types:

   groups:
     python-all:
       patterns:
         - "*"                          # claims every dependency
       update-types:
         - "minor"
         - "patch"                      # ...but never major

   No ignore entry covers cryptography, and no major bump appears anywhere in the sampled Dependabot history for this repo — only minor/patch (joserfc x2, pyjwt, mcp). Consistent with a structural exclusion rather than a one-off.

   This is not just cryptography — two ecosystems are affected

   ecosystem	group	patterns	update-types
   pip	python-all	*	minor, patch only
   npm (/site)	site-all	*	minor, patch only
   github-actions	actions-all	*	all types
   docker	docker-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-actions and docker are fine. That is the bug; this alert is a symptom of it.

   Proposed fix

   Add "version-update:semver-major" to python-all and site-all. Keeping majors inside the group is preferable to letting them flow ungrouped, because open-pull-requests-limit: 1 would 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 mcp major-version ignore stays as-is — that one is deliberate and documented (_compat.py patches 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.0

   Honest 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.
3. mlorentedev

   closed this as completedin 7676ad7on Aug 8, 2026
4. mlorentedev

   added 2 commits that reference this issue on Aug 8, 2026

   fix(deps): let major bumps reach pip and npm, and clear the cryptogra…

   ...

   This issue will close once commit 7676ad7 is merged into the 'master' branch.

   7676ad7

   docs(lessons): a group filter that excludes rather than batches (#340)

   ...

   This issue will close once commit 981c932 is merged into the 'master' branch.

   981c932