Fix(ci): verify-recipes PEP 740 sweep counts by exit code + date v0.11.0 as 2026-07-18#200
Merged
Merged
Conversation
…se 2026-07-18 verify-recipes' first scheduled run (2026-07-17) failed: the PEP 740 sweep reported 0/8 wheels verified even though pypi-attestations verified all 8. Root cause: as of pypi-attestations 0.0.29 the `OK:` line is written to stderr, so the step's stdout-only capture (`out=$(...)`) was empty and the `grep "^OK:"` counter matched nothing. The attestations themselves are valid — only the sentinel's counting was wrong. Fix: key the coverage count off the verifier's EXIT CODE (0 = verified) via `if out=$(... 2>&1); then ok=$((ok+1)); fi`, which is robust to output-stream placement and future format changes; `2>&1` keeps the OK/error line in the job log. Verified locally against the published v0.10.18 wheels (counts correctly). check_workflow_tools --strict, audit_workflow_permissions --strict, and zizmor all clean. Also: date the v0.11.0 release 2026-07-18 (the actual ship date) across CHANGELOG, README recent-releases, ROADMAP, capability-matrix, threat-model, cli-gui-parity, and the v0.12 plan; re-ran the FedRAMP drift probe fresh at the tag gate (clean — pins still match live upstream) and stamped UPSTREAM.json verified_at + the re-vendor provenance notes 2026-07-18 accordingly. No package code change; the fedramp emitter + conmon tests stay green.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
allenfbyrd
enabled auto-merge
July 18, 2026 18:45
allenfbyrd
added a commit
that referenced
this pull request
Jul 18, 2026
…estation discovery Second first-run defect in verify-recipes, masked until the PEP 740 counting fix (#200) let the run reach Recipe 3: the pinned cosign v2.4.1 cannot DISCOVER the SLSA provenance attestation that actions/attest-build-provenance stores via the OCI 1.1 referrers API — it verifies the image signature fine (Recipe 2 passed) but returns 'no matching attestations' for Recipe 3. Verified empirically against the published v0.10.18 image: cosign v2.4.1 fails; cosign v2.6.3 exits 0 with a valid in-toto envelope; gh attestation verify (any version) also succeeds — the attestation exists and is valid, only old-cosign discovery is broken. Fix: pin cosign-release v2.6.3 in verify-recipes.yml (with a comment recording the why), and add a 'requires cosign >= 2.6' note + the gh-attestation-verify alternative to docs/verification.md so consumers on older cosign are not misled by a false negative. Full local simulation of all 5 recipes against the published v0.10.18 artifacts: PASS (PEP 740 8/8, signature, attestation, gh attestation, SBOM+osv). check_workflow_tools --strict / audit_workflow_permissions --strict / zizmor / docs-health --strict all green; recipe-drift guard tokens intact.
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.
verify-recipes first-run fix + release-date correction
verify-recipes' first scheduled run (2026-07-17) failed — the PEP 740 sweep reported
0/8wheels verified even thoughpypi-attestationsverified all 8. Root cause: as of pypi-attestations 0.0.29 theOK:line goes to stderr, so the step's stdout-only capture (out=$(...)) was empty and thegrep "^OK:"counter matched nothing. The attestations are valid — only the sentinel's counting was wrong (confirmed empirically: the verify command exits 0 and prints OK to stderr).Fix: count by the verifier's exit code (
if out=$(... 2>&1); then ok=$((ok+1)); fi) — robust to stream placement and format changes;2>&1keeps the OK/error line in the job log. Verified locally against the published v0.10.18 wheels (counts correctly).check_workflow_tools --strict+audit_workflow_permissions --strict+ zizmor all clean.Also — date v0.11.0 as 2026-07-18 (the actual ship date) across CHANGELOG, README recent-releases, ROADMAP, capability-matrix, threat-model, cli-gui-parity, and the v0.12 plan. Re-ran the FedRAMP drift probe fresh at the tag gate (clean — pins still match live upstream) and stamped
UPSTREAM.jsonverified_at+ the re-vendor provenance notes 2026-07-18.Verification: full suite 4,947 passed; ruff, mypy, docs-health --strict 0 FAIL, doc-counts, parity, version-consistency, roadmap-currency, mirrors --check all green; no package code change.