feat(sbom): extract SHA-256 hashes from uv.lock for uv provider#533
Conversation
Parse uv.lock TOML to extract SHA-256 artifact hashes (from sdist or wheels entries) and attach them to the dependency graph, so generated CycloneDX SBOMs include per-component hash data. This enables the backend to compare artifact SHAs against the Trusted Libraries registry. Implements TC-4332 Assisted-by: Claude Code
Reviewer's GuideAdds SHA-256 hash extraction from uv.lock for uv-managed Python projects and wires it into the uv dependency graph so CycloneDX SBOMs include per-component hashes, updating uv golden fixtures accordingly. Sequence diagram for uv dependency data retrieval with hash attachmentsequenceDiagram
participant Caller
participant Python_uv
participant UvExport
participant UvLock
Caller->>Python_uv: _getDependencyData(manifestDir, workspaceDir, parsed, opts)
Python_uv->>Python_uv: _getProjectName(parsed)
Python_uv->>UvExport: _getUvExportOutput(manifestDir, opts)
Python_uv->>Python_uv: _parseUvExport(uvOutput, projectName, workspaceDir)
activate Python_uv
Python_uv-->>Python_uv: directDeps, graph
deactivate Python_uv
Python_uv->>UvLock: _attachHashesFromLockFile(workspaceDir/uv.lock, graph)
activate UvLock
UvLock->>UvLock: fs.readFileSync(lockFilePath, utf-8)
UvLock->>UvLock: parseToml(lockContent)
UvLock-->>Python_uv: graph entries updated with hashes
deactivate UvLock
Python_uv-->>Caller: { directDeps, graph }
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The new
_attachHashesFromLockFilehelper silently ignores both file read and TOML parse errors; consider at least debug-level logging so issues with malformed or missinguv.lockfiles are discoverable during troubleshooting. - The JSDoc for
_attachHashesFromLockFilestill describes thegraphentries as{name, version, children}while_getDependencyDatanow documentsGraphEntry; it would be good to align this type annotation with the actualGraphEntryshape to avoid confusion. - When attaching hashes, the code overwrites
entry.hashesunconditionally; if other parts of the pipeline might already populate hashes, you may want to append or merge rather than replace to avoid losing existing data.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The new `_attachHashesFromLockFile` helper silently ignores both file read and TOML parse errors; consider at least debug-level logging so issues with malformed or missing `uv.lock` files are discoverable during troubleshooting.
- The JSDoc for `_attachHashesFromLockFile` still describes the `graph` entries as `{name, version, children}` while `_getDependencyData` now documents `GraphEntry`; it would be good to align this type annotation with the actual `GraphEntry` shape to avoid confusion.
- When attaching hashes, the code overwrites `entry.hashes` unconditionally; if other parts of the pipeline might already populate hashes, you may want to append or merge rather than replace to avoid losing existing data.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
- Log errors when uv.lock cannot be read or parsed instead of silently ignoring, so issues are discoverable during troubleshooting - Align JSDoc graph parameter type with GraphEntry typedef - Skip hash assignment when entry already has hashes to avoid overwriting data from other pipeline stages Implements TC-4332 Assisted-by: Claude Code
|
/review |
|
@sourcery-ai review |
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The JSDoc types for the graph entry are inconsistent: the return type in
_getDependencyDatausesimport('./base_pyproject.js').default.GraphEntrywhile_attachHashesFromLockFileusesimport('./base_pyproject.js').GraphEntry, which should be aligned to the actual export to avoid tooling/type issues. - Consider avoiding
fs.readFileSyncandconsole.errorin_attachHashesFromLockFilefor better integration with the existing async flow and logging approach (e.g. use async I/O and the existing logger or a debug flag so SBOM generation doesn’t spam stderr on missing or malformeduv.lockfiles).
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The JSDoc types for the graph entry are inconsistent: the return type in `_getDependencyData` uses `import('./base_pyproject.js').default.GraphEntry` while `_attachHashesFromLockFile` uses `import('./base_pyproject.js').GraphEntry`, which should be aligned to the actual export to avoid tooling/type issues.
- Consider avoiding `fs.readFileSync` and `console.error` in `_attachHashesFromLockFile` for better integration with the existing async flow and logging approach (e.g. use async I/O and the existing logger or a debug flag so SBOM generation doesn’t spam stderr on missing or malformed `uv.lock` files).Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Align JSDoc GraphEntry type import, use async I/O instead of readFileSync, and remove console.error calls in _attachHashesFromLockFile. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Verification Report for TC-4332 (commit 424e569)
Overall: PASSAll acceptance criteria satisfied. The This comment was AI-generated by sdlc-workflow/verify-pr v0.9.1. |
Summary
uv.lockTOML to extract SHA-256 artifact hashes (fromsdist.hashorwheels[0].hash) and attach them to dependency graph entrieshashesarrays for uv-managed projectsImplements TC-4332
Test plan
🤖 Generated with Claude Code
Summary by Sourcery
Extract and attach SHA-256 hashes from uv.lock to uv dependency graph entries and propagate them into generated SBOMs for uv-managed projects.
New Features:
Tests: