chore: bump idna and pygments in uv.lock to clear Dependabot alerts#424
Conversation
Addresses the Dependabot security alerts that can be resolved while still supporting Python 3.9: - idna 3.10 -> 3.18 (GHSA: idna.encode() bypass, alert #32; first patched 3.15) - pygments 2.19.2 -> 2.20.0 (ReDoS in GUID regex, alert #27; first patched 2.20.0) Both patched versions still support Python 3.9 (idna requires >=3.8, pygments requires >=3.9), so the lock resolves to a single, non-forked version and the alerts clear. The remaining open alerts (urllib3, requests, python-dotenv, pytest, filelock) cannot be cleared without dropping Python 3.9: their first patched versions all require Python >=3.10, so uv forks the resolution and strands the vulnerable version on the py3.9 branch of the lock. These are the same exceptions noted in #398.
|
You know... I start to think nobody would get mad at astrapy for dropping a long-EOL'd version of Python. Let's get this one in, then we update min-python-required, so that the other CVEs can be addressed (filelock and the others).
|
Coverage reportfor commit: |
|
Generally all ok, but just a question for my own education: these are changes to the lockfile only (as opposed to pyproject explicit pinning). (I am interested in the answer because in the past I have addressed some earlier CVEs with pyproject-explicit pinning (of the |
@sl-at-ibm I recently had a task like this in Langflow and had the same question. My understanding is:
For If a future direct dependency actually forced an old vulnerable version, I think that would be a deeper dependency problem to address. Adding the transitive package directly to That was longer than i intended haha but i had to convince myself as well :) Does that make sense? |
sl-at-ibm
left a comment
sl-at-ibm
left a comment
There was a problem hiding this comment.
Thank you for the explanation! I think it makes sense, yes.
(A couple of times it has happened to me on some PRs that I found myself with a botched lockfile, so I deleted it and ran a fresh uv lock. This may potentially be trouble, I don't know -- perhaps the right thing in that case is to restore the lockfile from main and run "ordinary uv lock" as you mention.)
Anyway, there's no big risk in going forward like this PR does and keep an eye if some weird dynamics brings lower vulnerable versions around again (unlikely as it may be...)
So: LGTM!
2 participants
Summary
Resolves the Dependabot security alerts that can be cleared without dropping Python 3.9 support — a lock-file-only change (transitive dependencies, no
pyproject.tomlconstraints touched):idnaidna.encode()can bypass the CVE-2024-3651 fix>=3.8pygments>=3.9Both patched versions still support Python 3.9, so uv resolves each to a single (non-forked) version and the alerts clear.
Why the other 7 alerts are not included
The remaining open alerts —
urllib3(#30, #31),requests(#26),python-dotenv(#29),pytest(#28),filelock(#20, #23) — cannot be cleared while the project supports Python 3.9. Every one of their first-patched versions requirespython >=3.10:urllib3 2.7.0,requests 2.33.0,python-dotenv 1.2.2,pytest 9.0.3,filelock 3.20.3→ allrequires-python >=3.10.With
requires-python = ">=3.9", uv forks the resolution: it installs the patched version for py3.10+ but keeps the vulnerable version pinned for the py3.9 branch ofuv.lock. Dependabot scans the whole lock, so the alert stays open. (filelockalready demonstrates this today — it's at the safe 3.24.3 for py3.10+ but stuck at 3.18.0 for py3.9.) These are the same exceptions documented in #398 ("address dependabot vulns except incompatible with supporting py 3.9").Clearing those 7 requires a separate decision to drop Python 3.9 (already EOL as of Oct 2025), which is out of scope for a routine version-bump PR.
Test plan
ruff check astrapy tests— passesruff format --check astrapy tests— passesmypy astrapy tests— passes (215 files, no issues)pytest tests/base/unit— no new failures vs. baseline (idna/pygments are transitive deps unused at the astrapy layer)