Example Apache Tomcat SPDX - verified using online too - VALID
|
Hello Everyone,
During this week’s implementers call I suggested that we all try to create an SPDX SBOM from a common Apache Distribution.
I’ve attached a validated, SPDX V 2.2 SBOM for the Apache Tomcat distribution available here: https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.71/bin/apache-tomcat-9.0.71-windows-x64.zip
This Tag/Value file has been validated using the online tool validator, here: https://tools.spdx.org/app/validate/
Hopefully, use of one common distribution product package (Tomcat) from a well-known source (Apache Foundation) will provide us with a common target to compare implementation results, and best practices for SPDX.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
|
|
|
|
Dick Thanks for sharing. From a quick scan, I noticed that all of the FileChecksums are the same which doesn't seem quite correct. There are many files in the ZIP file. Is there a reason why the filenames don't contain any directory information as there are multiple instances of the same filename (e.g. index.jsp) with the only difference being the SPDXID? Running the SBOM through the ntia-conformance-checker throws up an issue with the DocumentNameSpace (the error message seems incorrect as it says it should not contain a # delimiter - it doesn't!) and the PackageVerificationCode not matching the correct format. The PackageVerificationCode appears to be expecting the checksum to be in lowercase which looks very strange seeing as uppercase fileechecksums seem to be considered valid although reading rhe SPDX Spec seems to indicate that SHA1 checksums should be all in lowercase. I can't see why the lowercase format has been mandated rathyetr than just allowing any hexdecimal digit (upper or lowercase). The issue is with DocumentNameSpace is in the Python library used by the ntia-conformance-checker so I have raised a PR (https://github.com/spdx/tools-python/issues/451) Regards Anthony |
|
|
|
Thanks for your analysis, Anthony.
DocumentNameSpace is not an NTIA minimum element, you are correct in stating that this is a bug in the checker code.
The checksums at the file level inherit from the distribution file and do not represent the hash values of each file.
The “missing filepaths” are due to a content model mismatch with NIST NVD. Adding the file path produces false negatives because NVD doesn’t include the file path on the component names. False negatives are very bad for risk awareness.
Thanks for taking the time to evaluate and provide feedback. This is precisely the type of discussion we need to be having among implementors.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx-implementers@... <spdx-implementers@...> On Behalf Of Anthony Harrison
Sent: Saturday, January 28, 2023 11:11 AM To: spdx-implementers@... Subject: Re: [spdx-implementers] Example Apache Tomcat SPDX - verified using online too - VALID
Dick
Thanks for sharing.
From a quick scan, I noticed that all of the FileChecksums are the same which doesn't seem quite correct.
There are many files in the ZIP file. Is there a reason why the filenames don't contain any directory information as there are multiple instances of the same filename (e.g. index.jsp) with the only difference being the SPDXID?
Running the SBOM through the ntia-conformance-checker throws up an issue with the DocumentNameSpace (the error message seems incorrect as it says it should not contain a # delimiter - it doesn't!) and the PackageVerificationCode not matching the correct format.
The PackageVerificationCode appears to be expecting the checksum to be in lowercase which looks very strange seeing as uppercase fileechecksums seem to be considered valid although reading rhe SPDX Spec seems to indicate that SHA1 checksums should be all in lowercase. I can't see why the lowercase format has been mandated rathyetr than just allowing any hexdecimal digit (upper or lowercase).
The issue is with DocumentNameSpace is in the Python library used by the ntia-conformance-checker so I have raised a PR (https://github.com/spdx/tools-python/issues/451)
Regards
Anthony
|
|
|
|
Keith Zantow
Hi all, I've also run Syft against this archive. A couple things of note: * Syft's Java handling has some room for improvement we already have some issues for, one of which I was unaware of appears to result in not including relationships between the files scanned and packages found within said JARs * The default behavior of Syft currently does not include SHA-1 hashes for files, so to get an optimal SPDX file the command used was: SYFT_FILE_METADATA_CATALOGER_ENABLED=true SYFT_FILE_METADATA_DIGESTS=sha1 syft apache-tomcat-9.0.71-windows-x64.zip -o spdx-tag-value > apache-tomcat-9.0.71-windows-x64.zip.spdx That said, I've attached the Syft generated SPDX file for this archive, which also is valid against the online validator tools. Again, thank you all for a great discussion this past meeting! Cheers, -Keith Zantow
On Fri, Jan 27, 2023 at 5:33 PM Dick Brooks <dick@...> wrote:
|
|
|
|
Keith,
This is fantastic. A couple of thoughts to consider:
In the NTIA domain, the first component “primary component” is the product.
The first component in the SBOM should be apache tomcat.
About to run this SPDX through a baseline VDR creation function.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx-implementers@... <spdx-implementers@...> On Behalf Of Keith Zantow via lists.spdx.org
Sent: Saturday, January 28, 2023 12:38 PM To: spdx-implementers@... Subject: Re: [spdx-implementers] Example Apache Tomcat SPDX - verified using online too - VALID
Hi all,
I've also run Syft against this archive. A couple things of note: * Syft's Java handling has some room for improvement we already have some issues for, one of which I was unaware of appears to result in not including relationships between the files scanned and packages found within said JARs * The default behavior of Syft currently does not include SHA-1 hashes for files, so to get an optimal SPDX file the command used was: SYFT_FILE_METADATA_CATALOGER_ENABLED=true SYFT_FILE_METADATA_DIGESTS=sha1 syft apache-tomcat-9.0.71-windows-x64.zip -o spdx-tag-value > apache-tomcat-9.0.71-windows-x64.zip.spdx
That said, I've attached the Syft generated SPDX file for this archive, which also is valid against the online validator tools.
Again, thank you all for a great discussion this past meeting!
Cheers, -Keith Zantow
On Fri, Jan 27, 2023 at 5:33 PM Dick Brooks <dick@...> wrote:
|
|
|
|
Keith Zantow
Hi Dick, Yes, as noted this past meeting Syft is not currently outputting the root document element in a NTIA compliant way -- we've had some internal conversations about improving this and plan to do so before long, but for transparency I thought I'd send what we have today. Cheers, -Keith Zantow On Sat, Jan 28, 2023 at 12:57 PM Dick Brooks <dick@...> wrote:
|
|
|
|
It’s all good Keith – we’re all just trying to get this working and your contribution is valuable – thanks for your contribution. We are all working to make SBOM better.
Keep up the great work.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx-implementers@... <spdx-implementers@...> On Behalf Of Keith Zantow via lists.spdx.org
Sent: Saturday, January 28, 2023 1:24 PM To: spdx-implementers@... Subject: Re: [spdx-implementers] Example Apache Tomcat SPDX - verified using online too - VALID
Hi Dick,
Yes, as noted this past meeting Syft is not currently outputting the root document element in a NTIA compliant way -- we've had some internal conversations about improving this and plan to do so before long, but for transparency I thought I'd send what we have today.
Cheers, -Keith Zantow
On Sat, Jan 28, 2023 at 12:57 PM Dick Brooks <dick@...> wrote:
|
|
|
