chore(deps): hand-roll four minor/patch bumps, keeping the setuptools CVE floor - #289
Merged
Merged
Conversation
… CVE floor Dependabot proposed exactly these four bumps across #285 and #287. Both were closed unmerged, for different reasons, and this replaces them. #287 was a security regression. Its compiled requirements.txt silently dropped the setuptools==84.0.0 entry - including the `# via -r requirements.in` / `# via torch` trace showing two consumers - while leaving requirements.in untouched and still implying setuptools is required. That pin is what closes GHSA-h35f-9h28-mq5c per requirements.in:15-21. Root requirements.txt is installed --no-deps --require-hashes in four workflows, so under --no-deps the file IS the install set and the advisory fix would genuinely not have been installed. The hash-pin gate could not have caught it: deleting a requirement removes its --hash= lines with it, so a pin gate sees a fully-hashed file and nothing wrong. check_lockfile_freshness.py is what catches this shape. #285 was a wrong-working-directory artifact. Its environments/requirements-ci.txt rewrote five provenance comments from `# via -r environments/requirements-ci.in` to `# via -r requirements-ci.in`, which is what the compiler emits when run from inside environments/ rather than the repo root. Neither PR regenerated environments/requirements.lock, which shares the hypothesis pin and would have gone stale against the file they did change. This branch regenerates all ten managed lockfiles through tools/update_dependencies.py from the repo root, keeping setuptools==84.0.0. Only five files carry a content change; the other five recompiled byte-identical. environments/requirements-ci-render.txt is tier 4 (hand-maintained, no .in source) and was edited per its own header recipe rather than compiled. Every hash was verified against the live PyPI JSON API rather than trusted from the Dependabot diff: all six changed digests across the three tier-4 packages resolve to a real published artifact of the stated version, one wheel and one sdist each. The tier-4 edit independently reproduced Dependabot's own blob (ec4c697) byte-for-byte, which is the strongest available check that the hand-edit and the tool agree. Gates run: check_lockfile_freshness.py --check (10/10 fresh and fully hashed), check_hash_pins.py (13 manifests, all pinned), check_doc_line_citations.py, check_doc_commit_refs.py, git diff --check, and the fast test suite. docs/sbom.json is deliberately NOT touched here. It is a generated supply-chain attestation and security.yml forbids hand-editing rows, so it is refreshed via the sanctioned download-the-CI-artifact path after the first run on this branch goes red. Expect exactly that one failure. Signed-off-by: Gavin Borges <gavinmborges1104@gmail.com>
Both artifacts were taken verbatim from the `python-sbom` artifact uploaded by the Security Scan run on this branch (run 32807744961), which is the path security.yml documents. They were NOT hand-edited: editing individual rows would fabricate freshness in an attestation downstream tooling reads as authoritative, which is the thing that gate exists to prevent. The gate reported exactly one drifted package - `docs/sbom.json` listed hypothesis==6.165.9 where the freshly generated artifact reported 6.165.10 - across 147 packages present in both. Verified before committing that the downloaded pair differs from the committed pair in that one row and nothing else: same 147 packages on both sides, one version delta, no additions and no removals. A larger row-count change would have meant something other than this bump moved, and would have needed explaining rather than committing. Signed-off-by: Gavin Borges <gavinmborges1104@gmail.com>
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.
Replaces #285 and #287, both closed unmerged. Applies the same four bumps they proposed -
hypothesis6.165.9 -> 6.165.10,pygments2.20.0 -> 2.21.0,fastjsonschema2.22.1 -> 2.22.2,nbformat5.11.0 -> 5.11.1 - without the two defects that made them unmergeable.Why #287 could not be merged
Its compiled
requirements.txtsilently dropped thesetuptools==84.0.0entry entirely, including the# via -r requirements.in/# via torchtrace showing two consumers, while leavingrequirements.inuntouched and still implying setuptools is required.That pin is what closes GHSA-h35f-9h28-mq5c per
requirements.in:15-21. Rootrequirements.txtis installed--no-deps --require-hashesin four workflows, so under--no-depsthe file IS the install set - the advisory fix genuinely would not have been installed.The hash-pin gate could not have caught this, and that distinction is the durable part: deleting a requirement removes its
--hash=lines with it, so a pin gate sees a fully-hashed file and nothing wrong.tools/check_lockfile_freshness.pyis what catches this shape.Why #285 could not be merged
Its
environments/requirements-ci.txtrewrote five provenance comments from# via -r environments/requirements-ci.into# via -r requirements-ci.in- what the compiler emits when run from insideenvironments/rather than the repo root. Neither PR regeneratedenvironments/requirements.lock, which shares thehypothesispin and would have gone stale against the file they did change.What this branch does instead
Regenerates all ten managed lockfiles through
tools/update_dependencies.pyfrom the repo root, keepingsetuptools==84.0.0. Only five files carry a content change; the other five recompiled byte-identical.environments/requirements-ci-render.txtis tier 4 (hand-maintained, no.insource, perCONTRIBUTING.md's dependency-tier table) and was edited following its own header recipe rather than compiled.Verification
Every hash was verified against the live PyPI JSON API rather than trusted from the Dependabot diff. All six changed digests across the three tier-4 packages resolve to a real published artifact of the stated version - one wheel and one sdist each.
The tier-4 hand-edit independently reproduced Dependabot's own blob (
ec4c697) byte-for-byte, which is the strongest available check that the hand-edit and the tool agree on that file.Gates run locally:
check_lockfile_freshness.py --check(10/10 fresh and fully hashed),check_hash_pins.py(13 manifests, all pinned),check_doc_line_citations.py,check_doc_commit_refs.py,git diff --check, and the full fast test suite via the pre-push gate.One expected CI failure
docs/sbom.jsonis deliberately not touched here. It is a generated supply-chain attestation andsecurity.ymlforbids hand-editing rows - editing them would fabricate freshness in an attestation. The SBOM freshness gate will go red once on this branch; the fix is the sanctioned path the workflow itself documents, downloading thepython-sbomartifact and committing it over the copies indocs/. Expect exactly that one failure and no other.