Add subject info the sbom #3529
Conversation
|
This is an example sbom when building locally: |
Good question ... [*] - Noting that the process for EA (Early Access) builds is still very much a work-in-progres and therefore we have plenty of opportunities to fix this. The current way of doing things was an MVP to make it work from the perspective of customers - there are plenty of reasons to fix that, and being able to make the SBOM more useful as per this PR is definitely another one! What do you think @andrew-m-leonard ? |
|
Also, I see you've changed it here but as a style note I personally prefer to have the comments all lined up in the file as it's more pleasing to the eye, but since this isn't code I wrote I won't require it to be changed ;-) The linter seems to have some objections though. |
|
As the artifacts are getting moved and renamed, I needed to add the final sbom generation at the very end to create the provenance with the final artifacts rather some intermediate state. Right now I use the final filename of the artifact as name of the component, but that is arbitrary, we could also other names that describe more conceptually and set the filename as property. So then the component name would be the same for EA and release builds, just the filename would be different which would also be reasonable imho. Regarding the formatting: I started to work on that as there were some typos, but realized I should not change the formatting in general, so please ignore that changes. The idea of the PR is to collect feedback about the way the sbom gets generated and the output. The code to achieve it is not clean at all atm. |
There was a problem hiding this comment.
@andrew-m-leonard Is there a reason why the main SBoM creation is before the creation of the final tar archives here?
Im think when this was originally added we were breaking new ground.. and my thoughts were on the JDK itself, and not the subsequent tar archive. This change seems reasonable to me. |
|
@netomi Based on the above is there anything else you want to do before taking this out of draft status? |
|
I will need some more cleanups and the other components need some work (static-libs especially as the logic that I used so far does not work for them). |
|
I worked on the PR. Now there is only a single generateSBoM method at the end instead of splitting it up in two parts. I changed the component names to "$COMPONENT Component" where component is one of JDK, JRE, STATIC-LIBS, SOURCES, TESTIMAGE, DEBUGIMAGE. The filename of each component is now encoded as property with key Filename. I did also some cleanups to avoid repeating the same snippets, e.g. when constructing filenames in an os independent way. Something that could be changed is that the properties for each component are very much the same, and could be captured not on component level but on metadata level, or we omit it in same cases like for sources, but its also fine to keep it like that imho. Attaching an example sbom generated locally using:
|
netomi
force-pushed
the
add-subject-info
branch
from
67a1a0d
to
3d880bc
Compare
|
it looks like there is no sha256sum tool on MacOS: what could be used otherwise? I found this: https://unix.stackexchange.com/questions/426837/no-sha256sum-in-macos Ah I found sha256File() in the prepareWorkspace.sh |
On mac I use: |
|
On Macos the sha works now, but on windows the result looks like this: |
…se plan joinPath for files that are passed to cygwin programs.
|
Looks like cygwin sha256sum tool does not like windows paths. Making sure that files passed to the tool are not OS specific paths but rather unix like paths. |
|
Added a method to get the target file name of a component (e.g. jre or testimage) that also considers the case where the target file name does not contain a -jdk pattern in it like in the build workflow (there the target file name is OpenJDK.tar.gz), which means that the build script will end up with the same name for all components. With this change, when no -jdk pattern is detected, just prepend the component name before the extension. |
|
From my side, I am done with this PR. The test failure is unrelated imho, and should be fixed by applying #3543. |
There was a problem hiding this comment.
I'm not an expert in this code (although more than I was a couple of weeks ago!) but this LGTM. We should look at the output (SBoM content) before and after this change (unless you already have a before & after pair you can add here?), but I'm ok with having this merged and see if it works, then fix up later if required.
|
|
||
| local sbomTargetName=$(getTargetFileNameForComponent "sbom") | ||
| # Remove the tarball / zip extension from the name to be used for the SBOM | ||
| if [[ "$OSTYPE" == "cygwin" ]] || [[ "$OSTYPE" == "msys" ]]; then |
There was a problem hiding this comment.
We could simplify this and not require the if clause by just stripping both e.g. `sbomTargetName=$(echo "${sbomTargetName}.json" | sed -e "s/.zip//" -e "s/.tar.gz//")
But I'm ok either way.
This fixes #3528 .
This is a draft PR to gather feedback on the used approach.
Right now I split up the sbom generation into 2 steps:
this has to be done after all archives have been created and moved to their final destination. We could also generate the sbom completely at the end, though I am not sure if no files should be modified in the target directory at all.