✨ feat(build): add SBOM timestamp and generator metadata - #3269
Merged
Merged
Conversation
auditwheel and bocpy both hand-roll the same CycloneDX shape virtualenv does, and bocpy is the one precedent that adds metadata.timestamp and metadata.tools rather than leaving them out. Neither precedent puts build-environment details (OS, Python version, toolchain) anywhere in the document: that's already covered separately by the SLSA build provenance attestation the release workflow generates, so duplicating it here would blur the SBOM/attestation split and risk reproducibility if a runner's exact environment string ever varied between otherwise identical builds. metadata.timestamp is derived from hatchling's own get_reproducible_timestamp(), the same SOURCE_DATE_EPOCH-aware helper it uses for the wheel's own zip entries, so a reproducible build keeps producing a byte-identical SBOM. metadata.tools names hatch_build.py as the generator without a version number, since it isn't an independently versioned package and ships in lockstep with virtualenv itself.
gaborbernat
added
the
security
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The embedded SBOM's
metadatablock only carries the rootcomponent.auditwheeland Microsoft'sbocpy, which hand-roll the same CycloneDX shape virtualenv does, both go further:auditwheelnames itself inmetadata.tools, andbocpyaddsmetadata.timestampplus a nestedmetadata.tools.componentsentry for its own generator script. Neither puts build-environment details like the OS or Python version anywhere in the SBOM. That's the SLSA build provenance attestation's job, and the release workflow already generates one; duplicating it here would blur the line between what an SBOM describes (composition) and what an attestation describes (the build process), on top of risking the same reproducibility bugserialNumberhad before #3268.hatch_build.pynow derivesmetadata.timestampfrom hatchling's ownget_reproducible_timestamp(), the helper it already uses for the wheel's zip entry timestamps, so settingSOURCE_DATE_EPOCHfor a reproducible build still produces a byte-identical SBOM. 🔁 I built the wheel twice with a fixedSOURCE_DATE_EPOCHand diffed the resultingmetadata.timestampandserialNumbervalues to confirm it.metadata.tools.componentsnameshatch_build.pyas the generator with no version number, since it has no version of its own and ships in lockstep with virtualenv.tasks/validate_sbom.pychecks both fields the same way it checksserialNumber.