Take the two pins the index has published past [#224] - #228
Merged
Conversation
`go run . pins` refused on the default branch because the workflow audit and
the static analysis engine were both behind what PyPI publishes, and the
comparison runs weekly on a schedule, so the refusal stood for two days with
nothing that would clear it but a change to this file.
go run . pins
zizmor: BEHIND, pinned 1.29.0, pypi says 1.30.0
semgrep: BEHIND, pinned 1.174.0, pypi says 1.176.0
4 pin(s) declared, 4 compared, 2 behind, 0 unresolved.
Run 2026-09-02 at 6541274, elided for length.
What this prevents is the drift each `why` field names: a workflow audit that
has stopped understanding the syntax it audits, and a rule engine release that
turns a pattern which refuses something into one that refuses nothing, both of
which leave every run green. Neither pin carries a checksum, because the
resolver compares against what the index publishes rather than against the
wheel, which is what those two entries already say.
The bump is written by hand rather than by a run of the comparison, which
reports and never writes: a machine that rewrote a version and its checksum in
one commit has proved nothing about the bytes it just trusted.
Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
The audit release the pin above moves to carries a new rule, and it refuses
two lines of this tree at the severity the gate is run at:
uvx --no-build "zizmor@1.30.0" --strict-collection --min-severity=low --format=plain .
help[self-repository]: use GitHub's dedicated self-repository syntax
--> ./.github/workflows/package-caller.yml:32:11
--> ./.github/workflows/release.yml:76:11
12 findings (10 suppressed, 2 safe fixes): 0 informational, 2 low, 0 medium, 0 high
Read 2026-09-02 from the run of that version on this branch, elided for length.
Both sites call the packing workflow, both are the only two calls to it in the
tree, and neither carries a reference, which is what the newer form requires:
grep -rn 'uses: ./.github/workflows/package.yml' .github/workflows/
.github/workflows/package-caller.yml:32: uses: ./.github/workflows/package.yml
.github/workflows/release.yml:76: uses: ./.github/workflows/package.yml
Run 2026-09-02 before this change.
What the newer form prevents is the older one resolving to a file a previous
step wrote into the workspace rather than to the file at this commit. The
workspace-relative spelling is a path on a runner, so a step that clones or
writes ahead of the call decides what runs; `$/` names the calling repository at
the commit that called, and cannot be pointed anywhere else.
This lands beside the pin rather than after it because the pin is what makes the
rule apply: at 1.29.0 the audit does not exist, and at 1.30.0 the gate refuses
these two lines, so a branch carrying only the pin cannot go green.
Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
This was referenced Sep 2, 2026
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.
What was wrong
The newest completed run of
Pinson the default branch concludedfailure,and #224 is the entry that records it. What it refused on is two of the four
pins in
pins.jsonsitting behind what the index publishes:Run 2026-09-02, elided for length. That run is from 2026-08-31, and the index
has moved once more since: semgrep is at 1.176.0 rather than the 1.175.0 the run
above read.
Run 2026-09-02 against
6541274. Nothing but a change topins.jsonclearsthat verdict: the comparison reports and never bumps, and it runs on a weekly
schedule, so the refusal stands until somebody writes the versions.
What this does
zizmormoves from 1.29.0 to 1.30.0 andsemgrepfrom 1.174.0 to 1.176.0.Nothing else in the file changes. Neither entry gains a checksum, because both
are resolved against what the index publishes rather than against the wheel,
which is what each
whyfield already states.The two versions are read by their workflows out of this file with
jq, sothere is no second copy of either to keep in step, and the invariant that
refuses a version written into a workflow step is what keeps it that way. Both
of those workflows run on this pull request, so the check that the new releases
still pass over this tree is made here rather than after the merge.
Why the drift is worth clearing rather than waiting out. The two
whyfieldsname the same failure from two directions: an audit that has stopped
understanding the syntax it audits, and a rule engine release that turns a
pattern which refuses something into one that refuses nothing. Both leave every
run green, so this is the drift with no other witness in this tree.
The means
pins.jsonand the verb that already reads it. The change is two values in thefile the comparison is written against, so it is decided by the same run that
found the drift, needs no language, runtime or dependency this tree does not
carry, and the claim above carries the command that produced it in both
directions. Writing the versions into the two workflow steps instead would be
refused by the invariant gate, which is the same rule read from the other side.
No second reader
Nothing on this board reviewed this change but the account that wrote it. The
evidence in place of one is the run below and the checks on this pull request,
which include the two tools whose versions this changes.
Closes
Closes #224.
What was run
Both run 2026-09-02 at
37782bf, the first commit of this branch. The secondcommit changes no value in
pins.json.The pin does not go green on its own, and the second commit is why
zizmor 1.30.0 carries a rule 1.29.0 does not, and the gate runs that tool at
--min-severity=low, so the release this pin moves to refuses two lines of thistree:
Read 2026-09-02 from the run of the first commit of this branch, elided for
length. So a branch carrying only the pin cannot go green, and the two changes
arrive together rather than one of them landing red.
Both sites are calls to the packing workflow and they are the only two in the
tree:
Run 2026-09-02 at
37782bf, before the second commit.$/names the calling repository at the commit that called and takes noreference;
./is a path on the runner's workspace, so a step that writes thereahead of the call decides what runs. GitHub documents the first as the
recommended form for a reusable workflow in the same repository, and the audit
that arrived with 1.30.0 asks for exactly that.
What that costs is stated rather than left to be met:
$/is unavailable onGitHub Enterprise Server. This repository is published from github.com, so the
form is free here and would not be everywhere.
The other tool in this bump needs nothing.
Static analysis (semgrep)passed at1.176.0 on the first commit of this branch.
Two files this issue does not name
.github/workflows/release.ymland.github/workflows/package-caller.ymlarenot files #224 is about. They are here because the pin cannot land without them,
and the change to each is one line. No open pull request touches either:
Run 2026-09-02, before the second commit was pushed.
Why this is the second pull request for one change
#227 carries the same one-line change to
pins.jsonand noSigned-off-bytrailer, so the DCO gate refused it:
Run 2026-09-02. A trailer cannot be added to a commit that is already pushed
without rewriting the branch, and this project does not force-push, so the
correction is pushed under a new name and #227 is closed with the reason in its
body rather than repaired in place. The two heads carry the same tree:
Run 2026-09-02.