Skip to content

feat: record git cherry-picks in SBOMs - #2221

Draft
sil2100 wants to merge 2 commits into
chainguard-dev:mainfrom
sil2100:sbom-cherry-picks
Draft

feat: record git cherry-picks in SBOMs#2221
sil2100 wants to merge 2 commits into
chainguard-dev:mainfrom
sil2100:sbom-cherry-picks

Conversation

@sil2100

@sil2100 sil2100 commented Nov 7, 2025

Copy link
Copy Markdown
Member

Currently cherry-picks, similar to patches, go unnoticed in our apk SBOMs. But unlike patches, which are hard to describe in SBOMs as their contents can be custom, cherry-picks come from upstream and can be registered. There's multiple ways to do it, but here I proposed recording those in externalRefs for the source. SPDX 2.3 supports an arbitrary "OTHER" category which I propose to use here for this. There is also "SECURITY", which is nice as it is something that tools already know how to parse, but it has some shortcomings: first, it's purpose is for security fixes. Second, the locator needs to be a direct url - which is nice, but redundant and might be a bit arbitrary.

Thoughts?

Signed-off-by: Łukasz 'sil2100' Zemczak <lukasz.zemczak@chainguard.dev>
Signed-off-by: Łukasz 'sil2100' Zemczak <lukasz.zemczak@chainguard.dev>
Comment thread pkg/config/config.go

@sergiodj sergiodj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @sil2100! Leaving a small nit for now; I haven't had the chance to do an in-depth review yet.

Comment thread pkg/config/config.go
@sil2100

sil2100 commented Nov 13, 2025

Copy link
Copy Markdown
Member Author

@sergiodj sent some replies to your comments. Tell me what you think! Would you have some time to review this in more depth?

@sergiodj

Copy link
Copy Markdown
Member

@sergiodj sent some replies to your comments. Tell me what you think! Would you have some time to review this in more depth?

Thanks, @sil2100. I just had those two questions that you've already answered. I sat down and looked at the code more carefully, and it seems great. Thanks a lot for doing this in such short notice! You rock.

@sil2100

sil2100 commented Nov 24, 2025

Copy link
Copy Markdown
Member Author

I still like this approach that I took here, but there are discussions of switching this to a directly-downloadable url (like in the SECURITY case). But I'm unsure which way to go for now.

@sil2100
sil2100 marked this pull request as draft December 1, 2025 11:46
@sergiodj

sergiodj commented Dec 1, 2025

Copy link
Copy Markdown
Member

@sil2100 I like this approach as well. Can we proceed with this one at least temporarily? Is it a problem if we withdraw these new fields in the future (in favour of a different approach, for example)?

@sil2100

sil2100 commented Dec 1, 2025

Copy link
Copy Markdown
Member Author

I'd love to go with this approach, but I am worried about withdrawal/change later! Since if people start expecting the reference to be one thing and then it's suddenly another, that feels problematic. Of course, there's still the option of having BOTH fields. Like, keep the cherry-pick-commit-id fields as proposed here and then supplement those with references with downloadable urls as we were discussing separately.
Let's wait at least this week. I want to see if there's a bigger push on the other 'download url' based solution in the next days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants