fix(release,ci): hold sigstore at 4.4.0 per owner ruling, make it stick, and audit the lock (BACKLOG #332)

[wshallwshall]

Summary

Holds the release signing toolchain at sigstore==4.4.0 per owner ruling, adds a Dependabot
ignore so it stays there, and closes an audit gap that made both of those safe. Four commits, one
layer each.

The version is not reopened here. Owner ruling 2026-08-22, re-affirmed 2026-09-03.

#	Commit	Layer
1	e0bfb91e7	Record the shipped mechanism; raise the discrepancy (written before the ruling)
2	127587adf	The pin: pyproject.toml, uv.lock, ci/locks/release-tools.lock
3	144abab09	Make it stick: dependabot.yml ignore + security.yml audit backstop
4	3c3f778ae	Correct every record that argued for 4.5.0

Why the pin moved back

a9354808e (2026-08-29) landed the hashed-lock mechanism correctly but authored the pin as 4.5.0,
reasoning that the 5-day cooldown had expired. That argument was published on PR 531 at
2026-08-26T23:46:18Z and retracted by its own author at 2026-08-27T02:45:36Z — two days before it
shipped. Its words: "I checked whether the ADR's premise had expired. I never checked whether the
question had since been answered." So release.yml's comment was not merely written against
pre-ruling main; it restated a withdrawn position.

The cooldown never reached the ruling in either direction, which is what makes the ruling robust.
It expired 2026-08-02; the first ruling came twenty days later. Verified in the owner packet at commit
f3d3d1be6: zero occurrences of cooldown, 2026-08-02, 5-day, ages out or publish date,
against controls that fired in the same window (sigstore 3, 4.4.0 3, 4.5.0 2). One correction
to the numbers I was given: 332 is 0 hits in that 30-line section, not 6.

Neither version has a patch line, so patch availability does not discriminate. Measured against
PyPI 2026-09-03 with a control: 4.x is 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 and nothing else. The
3.x series did ship patches (3.5.1, 3.6.7) — my control — so a future 4.4.1 is possible, and the
ignore is scoped to leave that track open. The record does not say 4.4.0 is uniquely unpatchable.

The dependabot.yml:55 conflict: I took (a), and it is only sound because of a fix

dependabot.yml records that the == pins in [dependency-groups] are deliberately not ignored,
so the hash-pinned toolchain keeps moving rather than rotting into "pinned, stale, unpatched."

I added the ignore and amended the policy to record the carve-out — option (a). The reasoning:
that policy is about versions nobody has decided. It keeps an unattended pin fresh. sigstore's
version is an owner ruling, so the failure mode inverts — a weekly PR does not refresh neglect, it
re-proposes a declined version, and merging it silently reverses a decision. That is not
hypothetical: it is what happened in a9354808e.

But the staleness half of that policy does still bind, and honouring it required a fix. An
ignore also suppresses the security track for its range. The file already accepts that for
annotated-types and ruff on one explicit ground: pip-audit still detects a withheld fix and reds a
required gate within ~24h. That backstop did not exist here.

Gap found and closed: a9354808e added ci/locks/release-tools.lock to the export set and the
byte-diff gate but not to security.yml's audit step, which ran pip-audit over requirements.lock,
ci-scanners.lock and ci-quality.lock only. From 2026-08-29 the release signing closure was the one
committed lock nothing audited — hash-pinned, therefore sticky, therefore exactly the posture ADR 0034
calls worse than floating. pip-audit -r ci/locks/release-tools.lock --desc now runs beside the other
two, and each side's comment names the other, so removing one without the other is caught by reading
either. If that audit line ever goes, the ignore entry must go with it.

Scoped >=4.5.0, not to the package. Consequence stated: a CVE in sigstore's closure now reds a
required gate — wanted behaviour for the closure that signs the wheel, sdist, SBOM and VEX.

Records corrected

• ADR 0034 had two false assertions, both that sigstore is absent from every lock: the section 3
  register row at :206 and the residuals row at :358, read at 46ea10a7. Marked in place, not
  deleted. A 2026-09-03 amendment records the sequence and the discharged re-evaluation clause.
• The residual's reasoning contained a false counterfactual, and that is the transferable part: it
  assumed routing sigstore through the lock would force 4.5.0, so it treated "hash-lock it" and
  "keep 4.4.0" as exclusive. A group carries its own specifier. They were never in tension, and that
  coupling held a real gap open for five weeks.
• The :350 citation was wrong in four places in the backlog: close #1106 (already shipped) and file #1223 -- http_auth_user leaks verbatim #332 row. :350 is a blank line and was
  wrong at every commit. Now anchored on the row name, with the line and the commit it was read at.
• release.yml's "ON THE VERSION" comment now records the ruling and says not to re-derive the
  argument.
• dependabot.yml said SIX exported artifacts; it has been seven since a9354808e.

Still open

#332 stays OPEN, and step 6 is now the only thing in it. build and cyclonedx-bom remain inline
in the same privileged job. cyclonedx-bom is half of a byte-identical pair — release.yml:326 and
security.yml:367 — that test_sbom_install_is_byte_identical_in_release_and_security requires to
stay identical, so both halves must move in one commit or that test reds.

A smaller residual is recorded in the row: nothing pins release-tools.lock into the DEP-1 set,
because test_dep1_lock_resync_lockstep.py is satisfied by set equality between the two workflows.

Checks

Ran locally:

• pytest on test_ci_venv_pinning.py, test_dep1_lock_resync_lockstep.py, test_new_dependency_check.py,
  test_release_pipeline.py, test_dependabot_automerge_guardrails.py, test_security_posture.py,
  test_install_instruction_provenance.py — 163 passed, 7 skipped.
• DEP-1 re-export, control first: with the CI-pinned uv==0.12.0, the unchanged tree re-exported
  byte-identically (DIFFS=0), so the instrument matches CI's. After the change: uv lock --check
  passes and all seven exports match the committed tree. All six pre-existing artifacts stayed
  byte-identical — no contamination, so the semgrep-style excluded-by-decision call was never
  reached.
• ruff check / ruff format --check, backlog_status_check.py, ledger_check.py,
  scan_forbidden.py, control_char_check.py, and actionlint via pre-commit — all pass. The leak
  gate blocked one commit for an internal branch slug I had cited; removed, not allowlisted.
• Not run, and not the gate: mypy and the full pytest suite. No Python source changed.
• Hosted-runner only, unread by me: the pip-audit legs themselves, windows-service-smoke, and
  anything needing the Actions environment. The new pip-audit -r ci/locks/release-tools.lock line
  has never executed — read it on this PR's security.yml run before merging.

Testability caveat

release.yml runs only on a tag push or workflow_dispatch, so no PR CI leg executes the
signing path. The guards assert the lock exists, pins sigstore exactly, is fully hashed and is
installed with --require-hashes; they cannot assert it installs. The first real run of this change
is a release. Per ADR 0034's protocol: dry-run via workflow_dispatch and read the log before the
next tag. That has not happened.

Auto-merge not armed. #332 claimed via scripts/coord/claim.ps1; release it when this lands.

🤖 Generated with Claude Code

[wshallwshall]

LANDER: applying reviewed under an explicit owner override. The owner has suspended the reviewer process and directed that this label be applied as needed to clear the gate.

SO READ THIS LABEL AS A BYPASS TOKEN, NOT A REVIEW. It records that the gate was cleared by instruction. It does not assert that anyone read this diff, and no later reader should infer one from it.

What I can say: this PR appeared in a read-only pre-verification sweep of all 59 non-draft open PRs (per-PR defect read, plus pairwise git merge-tree against every PR sharing a non-BACKLOG file), and no blocking defect was recorded against it. That sweep did not run any tests, and CI has been down for hours, so nothing here has a current green.

-- Lander