feat(pep621): surface uv.lock transitive deps for osvVulnerabilityAlerts#44262
Open
khvn26 wants to merge 4 commits into
Open
feat(pep621): surface uv.lock transitive deps for osvVulnerabilityAlerts#44262khvn26 wants to merge 4 commits into
khvn26 wants to merge 4 commits into
Conversation
Emit registry-sourced lockfile-only packages as disabled deps so OSV can match them, and re-enable remediation only when a fixed version exists for a matched advisory.
RahulGautamSingh
left a comment
RahulGautamSingh
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for the PR! It has been a widely asked feature which we have implemented and then reverted for npm ie. transitiveRemediation so please give the team sometime to build a consensus on this.
Also, due to summer holidays it could take some time for the reviews and discussions.
I'll in post my review of the implementation soon.
Comment on lines
+224
to
+226
| // The index a package was resolved from, if any. Absent for the workspace | ||
| // root and for virtual/editable/path/git packages, which cannot be | ||
| // remediated by `uv lock --upgrade-package`. |
Collaborator
There was a problem hiding this comment.
use jsdoc comment
Comment on lines
+1130
to
+1131
| // remediation must override a disabled dependency, e.g. a transitive | ||
| // dep surfaced from a lockfile |
Comment on lines
+603
to
+605
| // Remediate even when updates are otherwise disabled for the dependency, | ||
| // e.g. transitive deps surfaced from a lockfile. Consistent with how | ||
| // vulnerability alerts already override schedule and minimumReleaseAge. |
| 'https://pypi.org/simple/', | ||
| ]); | ||
|
|
||
| function isDefaultPypiRegistry(registryUrl: string): boolean { |
Collaborator
There was a problem hiding this comment.
only used once, inline this
| // Remediate even when updates are otherwise disabled for the dependency, | ||
| // e.g. transitive deps surfaced from a lockfile. Consistent with how | ||
| // vulnerability alerts already override schedule and minimumReleaseAge. | ||
| enabled: true, |
Collaborator
Author
There was a problem hiding this comment.
Yeah I can see how this can be regarded as too broad.
One way to make this cleaner could be to add a dedicated lockfile-only skipReason and have the OSV processor clear it when we need to push a fix bump.
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
2 participants
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.
Changes
In this PR, we let
osvVulnerabilityAlertsremediate vulnerabilities in transitive (lockfile-only) dependencies for theuvmanager.Today the pep621/uv manager only attaches
lockedVersionto dependencies declared inpyproject.toml. Packages that exist solely inuv.lockare parsed and then discarded, soosvVulnerabilityAlertscan never see a CVE in an indirect dependency.lockFileMaintenanceis the only current workaround and it isn't security-scoped.This surfaces those transitive packages so the existing vulnerability machinery can act on them.
UvProcessor.extractLockedVersionsnow emits each registry-sourced package that isn't already a declared dependency as aPackageDependencywithdepType: 'uv.lock', itslockedVersion, andenabled: false. Because they're disabled, they produce no routine updates.UvLockfileschema now captures each package'ssource.registry. The workspace root and any packages not resolved from an index have no registry and are skipped. Non-default indexes are carried through asregistryUrls.osvVulnerabilityAlertsnow setsenabled: true. A disabled dependency is therefore re-enabled only when a fixed version exists for a matched advisory. That rule is applied at thepre-lookupstage, before theenabled === falsegate, so remediation flows into the existinguv lock --upgrade-package <name>call.The re-enable on the generated rule is the one cross-ecosystem behavior change: a vulnerable dependency that a user has otherwise disabled will now get a remediation PR when a fix is available. This is consistent with how vulnerability alerts already override
scheduleandminimumReleaseAge.The same mechanism would generalize to other lockfile managers (poetry, PEP 751, cargo); this PR keeps it to uv as a first implementation.
Some quirks I've noticed and would like to point out/discuss:
uv.lockasregistryUrls. Credentials from those come fromhostRulesthe same way it's done for non-transitive deps.pyproject.tomlfiles sharing oneuv.lock, we can get multiple remediations for the same transitive dep. Not sure if Renovate dedupes those further down the line, or we need to dedup earlier.Context
Please select one of the following:
Related discussions: #36793, #22049. I opted to open a PR with a working, tested implementation rather than only a proposal, but I'm very happy to convert this to a discussion-first conversation if you'd rather agree the approach before reviewing code.
AI assistance disclosure
Did you use AI tools to create any part of this pull request?
The code and tests were written by Claude Code (model: Claude Opus 4.8), with me directing the work, reviewing each change, and running the test suite.
Documentation (please check one with an [x])
(The new
uv.lockdepTypecarries a description viadep-types.ts, which feeds the generated manager docs.)How I've tested my work (please select one)
I have verified these changes via:
Unit tests: added an extract test covering transitive emission, and asserted the generated vulnerability rule now sets
enabled: true.Reproduction repo and the resulting PR: