ci(release): evaluate dependency markers in the SBOM check - #29
Merged
Conversation
Found by provide-foundation's v0.4.3 release, which reached PyPI and left its GitHub release with no artifacts and no signatures. This repository carries identical code and would do the same on its next tag. Sigstore: both signing steps pinned gh-action-sigstore-python at v3.0.0, from July 2024, which installs `sigstore ~= 3.0`. sigstore-python 3.x bundles a TUF root that can no longer verify Sigstore's production root: tuf.api.exceptions.UnsignedMetadataError: root was signed by 0/3 keys raised from TrustedRoot.production() before anything is signed. Signing does not degrade, it aborts -- the package reaches PyPI and the GitHub release gets no artifacts and no signatures at all. v3.1.0 moved the action to sigstore-python 4.x for Rekor v2; v3.5.0 is current, and rekor-version still defaults to 1 in the action's 3.x series, so bundle format and the dist/*.sigstore.json upload glob are unaffected. SBOM: the dependency-closure check read every Requires-Dist and demanded each name appear in the document, skipping only lines containing the literal "extra ==" -- a hand-rolled evaluation of one marker, blind to every other. A dependency carrying any other marker, such as `tzdata; sys_platform == "win32"`, was demanded on a runner where the marker correctly keeps it uninstalled. Markers are now evaluated with packaging, against an empty extra, under the interpreter of the venv the document describes. packaging is installed after the SBOM is generated so it is not itself published as a component. Both fixes are ports of provide-foundation and provide-foundry, where they are already merged and where provide-foundry 0.4.1 shipped through them cleanly.
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.
Found by provide-foundation's v0.4.3 release. This repository carries the identical SBOM check and would hit it the moment it declares its first conditional dependency.
SBOM — a marker matched as a substring
The dependency-closure check demanded every
Requires-Distname appear in the document, skipping only lines containing the literal"extra =="— a hand-rolled evaluation of one marker, blind to every other. A dependency carrying any other marker (tzdata; sys_platform == "win32"is how provide-foundation found it) was demanded on a runner where the marker correctly keeps it uninstalled.Markers are now evaluated with
packaging, against an emptyextra, under the interpreter of the venv the document describes.packagingis installed after generation so it is not itself published as a component.Provenance
Both fixes are ports of provide-foundation and provide-foundry, where they are merged. provide-foundry 0.4.1 shipped through this exact pipeline cleanly on the first attempt — SBOM job green, signing green, 9 assets attached — which is the evidence that both failure modes are actually dead rather than merely reasoned about.