-
Notifications
You must be signed in to change notification settings - Fork 2.6k
feat: implement RFC 3553 to add SBOM support #13709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
Much respect for your contribution. From my kind reminders, it seems appropriate to modify the documentation of the corresponding sections, e.g. Configuration, Environment Variables. |
Thanks for the reminder, @heisen-li. Would love to see a doc update, though we should probably focus on the design discussion first, as the location of the configuration is not yet decided. (See rust-lang/rfcs#3553 (comment)). |
One approach for the docs (if this is looking to be merged) is to put the env and config documentation fragments in the Unstable docs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just note that I reviewed this as-is, didn't really think too much for the design itself. Thank you for working on this!
☔ The latest upstream changes (presumably #13571) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I like the idea of having this PR to explore SBOM format. I'll post back issues we've found so far to the RFC. Thank you :)
☔ The latest upstream changes (presumably #13992) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased the PR. |
☔ The latest upstream changes (presumably #13900) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #13947) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #14576) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've the PR to address most of the feedback from @epage. Thanks!
I re-wrote the algorithm for building the sbom graph and made changes to the format. There's also now documentation for the format in unstable.md
that should help reviewers understand what it's looking like.
Before merging, I still want to add more test coverage for additional cases.
|
||
/// Describes a package dependency | ||
#[derive(Serialize, Clone, Debug)] | ||
struct SbomPackage { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently packages, since the crates within the package should have the same dependency set & profile if compiled in the same invocation. The existing algorithm is merging units within the same package.
If there's a reason to move to crates instead and have more nodes in the graph, I'm open to that, but I currently don't see one.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I've updated the PR and it should be ready for another round of review. Notable changes include:
|
Adds a new option `build.sbom` that adds generation of a JSON file containing dependency information alongside compiled artifacts.
Huge thank you @arlosi & to the cargo team for investing the time & effort to get this feature integrated. 🎉 |
Update cargo 11 commits in 1d1d646c06a84c1aa53967b394b7f1218f85db82..2622e844bc1e2e6123e54e94e4706f7b6195ce3d 2025-02-21 21:38:53 +0000 to 2025-02-28 12:33:57 +0000 - Bump `cc` to 1.2.16 to fix `x86` windows jobs in rust-lang/rust CI (rust-lang/cargo#15245) - refactor(tree): Abstract the concept of a NodeId (rust-lang/cargo#15237) - feat: implement RFC 3553 to add SBOM support (rust-lang/cargo#13709) - refactor(tree): Abstract the concept of an edge (rust-lang/cargo#15233) - chore: bump openssl to v3 (rust-lang/cargo#15232) - fix(package): Register workspace member renames in overlay (rust-lang/cargo#15228) - Implemented `build.build-dir` config option (rust-lang/cargo#15104) - feat: add completions for `--manifest-path` (rust-lang/cargo#15225) - chore: semver-check build-rs against beta channel (rust-lang/cargo#15223) - chore: depend on openssl-sys to correctly pin its version (rust-lang/cargo#15224) - chore: dont check cargo-util semver until 1.86 is released (rust-lang/cargo#15222)
Is this supposed to work with |
IIRC that hasn't yet been discussed, but personally I think it should |
What does this PR try to resolve?
This PR is an implementation of RFC 3553 to add support to generate pre-cursor SBOM files for compiled artifacts in Cargo.
How should we test and review this PR?
The RFC 3553 adds a new option to Cargo to emit SBOM pre-cursor files. A project can be configured either by the new Cargo config field
sbom
.or using the environment variable
CARGO_BUILD_SBOM=true
. Thesbom
option is an unstable feature and requires the-Zsbom
flag to enable it.Check out this branch & compile Cargo. Pick a Cargo project to test it on, then run:
All generated
*.cargo-sbom.json
files are located in thetarget
folder alongside their artifacts. To list all generated files use:then check their content. To see the current output format, see these examples.
What does the PR not solve?
The PR leaves a task(s) open that are either out of scope or should be done in a follow-up PRs.
Additional information
There are a few things that I would like to get feedback on, in particular the generated JSON format is not final. Currently it holds the information listed in the RFC 3553, but it could be further enriched with information only available during builds.
During the implementation a number of questions arose:
build.sbom
orprofile.*.sbom
Thanks @arlosi, @RobJellinghaus and @lfrancke for initial guidance & feedback.