SBOM required for tzdata2025b and tzcode2025b
Hi team, Could you please share the SBOM for tzdata2025b and tzcode2025b? Regards, Sahil
On 2025-04-04 00:48, Sahil Sharma D via tz wrote:
Could you please share the SBOM for tzdata2025b and tzcode2025b?
If you download the public domain source, it is up to you to document the tools you use to render the code and data into useful binary forms. If you install binary packages from an open source distribution, it is up to you to document the tools they tell you they use to render the code and data into useful binary forms. If you install binary packages from a commercial vendor, it is up to you to ask them to document and share with you the tools they use to render the code and data into useful binary forms. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On Apr 4, 2025, at 2:36 PM, Brian Inglis via tz <tz@iana.org> wrote:
On 2025-04-04 00:48, Sahil Sharma D via tz wrote:
Could you please share the SBOM for tzdata2025b and tzcode2025b?
If you download the public domain source, it is up to you to document the tools you use to render the code and data into useful binary forms.
If you install binary packages from an open source distribution, it is up to you to document the tools they tell you they use to render the code and data into useful binary forms.
If you install binary packages from a commercial vendor, it is up to you to ask them to document and share with you the tools they use to render the code and data into useful binary forms.
I.e.: The software bills of materials for tzdata2025b and tzcode2025b would be the result of running "tar tf" on the corresponding tarballs (possibly after decompressing if the version of the tar command on your platform doesn't handle gzipped files). That's all there is. Those contain no binary files compiled by any tools; compiled versions of the code and binary TZif files are produced by other suppliers such as operating system suppliers. You'd have to ask them for *their* software bills of materials.
On 2025-04-04 16:50, Guy Harris via tz wrote:
The software bills of materials for tzdata2025b and tzcode2025b would be the result of running "tar tf" on the corresponding tarballs (possibly after decompressing if the version of the tar command on your platform doesn't handle gzipped files).
Software Bills of Material (SBOMs) are more complicated than that these days, unfortunately. They come in multiple flavors (CycloneDX, SPDX, SWID) with different audiences, and they are associated with other standards (ISO 27001, NIST, CIS Controls) that are rarely heard of outside of the relevant specialties. Since Sahil didn't specify a context, it's hard to know what's exactly being asked for. That being said, I expect that we don't supply anything that would conform to any of the more-formal SBOM definitions Sahil is probably thinking of. Our closest approximations to SBOMs are the release announcements[1]. Although most of what we ship is edited by hand, some of it is generated by programs. I typically use GNU Tar and Gawk as packaged by recent Ubuntu, and I don't bother to specify these programs' versions or provenances. The philosophy has been that you can use any POSIX-conforming 'awk' implementation, and any sufficiently-recent GNU Tar, to generate the same output byte-for-byte, and to some extent this is the opposite of the SBOM philosophy since we're saying the provenance should not matter. Perhaps we should add something about SBOMs to theory.html, if only to say something along the lines of the above. [1]: https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest
On 2025-04-05 02:43, Paul Eggert via tz wrote:
On 2025-04-04 16:50, Guy Harris via tz wrote:
The software bills of materials for tzdata2025b and tzcode2025b would be the result of running "tar tf" on the corresponding tarballs (possibly after decompressing if the version of the tar command on your platform doesn't handle gzipped files).
As source is not functional, I doubt any SBOM related to that is relevant, rather only the generated binaries, as Guy expressed more tersely than I in his second paragraph.
Software Bills of Material (SBOMs) are more complicated than that these days, unfortunately. They come in multiple flavors (CycloneDX, SPDX, SWID) with different audiences, and they are associated with other standards (ISO 27001, NIST, CIS Controls) that are rarely heard of outside of the relevant specialties.
That was why I did not go further in any explanation: asking about a source product, not specifying any build environment, nor output format, suggests perhaps a poorly specified and/or understood assignment, whether academic or commercial, and tools, output format, or input to any SBOM is a concern of downstream projects and their users, not that of this project.
Since Sahil didn't specify a context, it's hard to know what's exactly being asked for. That being said, I expect that we don't supply anything that would conform to any of the more-formal SBOM definitions Sahil is probably thinking of. Our closest approximations to SBOMs are the release announcements[1].
That should be enough for most to understand that tzcode utilities should also be added to any tzdata SBOM.
Although most of what we ship is edited by hand, some of it is generated by programs. I typically use GNU Tar and Gawk as packaged by recent Ubuntu, and I don't bother to specify these programs' versions or provenances. The philosophy has been that you can use any POSIX-conforming 'awk' implementation, and any sufficiently-recent GNU Tar, to generate the same output byte-for-byte, and to some extent this is the opposite of the SBOM philosophy since we're saying the provenance should not matter.
I think that should be solely a downstream concern of project users that have SBOM requirements and funding to cover that.
Perhaps we should add something about SBOMs to theory.html, if only to say something along the lines of the above.
[1]: https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest
It would be kind to point out or reference your documentation of generation, build, and execution library and utility dependencies, which is more than most upstream source projects provide, as those are dependent on the platform, environment, and its releases. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-04-05 09:35, Brian Inglis wrote:
On 2025-04-05 02:43, Paul Eggert via tz wrote:
On 2025-04-04 16:50, Guy Harris via tz wrote:
The software bills of materials for tzdata2025b and tzcode2025b would be the result of running "tar tf" on the corresponding tarballs (possibly after decompressing if the version of the tar command on your platform doesn't handle gzipped files).
Software Bills of Material (SBOMs) are more complicated than that these days, unfortunately. They come in multiple flavors (CycloneDX, SPDX, SWID) with different audiences, and they are associated with other standards (ISO 27001, NIST, CIS Controls) that are rarely heard of outside of the relevant specialties. ...
I think that should be solely a downstream concern of project users that have SBOM requirements and funding to cover that.
Perhaps we should add something about SBOMs to theory.html, if only to say something along the lines of the above.
[1]: https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest
It would be kind to point out or reference your documentation of generation, build, and execution library and utility dependencies, which is more than most upstream source projects provide, as those are dependent on the platform, environment, and its releases.
I just ran across this book title which seemed relevant to some queries and requests: How About Never - Is Never Good for You? -- Bob Mankoff ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-04-05 01:43, Paul Eggert wrote:
Perhaps we should add something about SBOMs to theory.html, if only to say something along the lines of the above.
After looking into this a bit more, it appears that a good home for this might be the Makefile, as it already talks about POSIX compatibility. So I installed the attached proposed patch.
participants (4)
-
Brian Inglis -
Guy Harris -
Paul Eggert -
Sahil Sharma D