Repository navigation
fix(ci): lock entry points at the commit, not the tag object - #594
Merged
Merged
Conversation
…g object The actions.lock entry for haskell-actions/setup@v2.12.1 recorded 0f7370cc, the annotated TAG object, instead of the commit it points to (0f8e8c99). gh actions-lock --verify rejects it as an unreachable pin, which fails the Scorecard reconciliation step: Scorecard reconciliation failed: Native action-lock verification failed for .github/workflows/casket-pages.yml Dereferenced via repos/haskell-actions/setup/git/tags/0f7370cc -> object.type=commit sha=0f8e8c99d88aeb3fbfd523f1ef2c6f762d10d64d (git/commits/<sha> returns 200). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
Contributor
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
hyperpolymath
enabled auto-merge (squash)
October 6, 2026 21:04
Contributor
|
Add Carrot credits or activate Agent usage billing to use Autopilot |
7 of 13 tasks
hyperpolymath
added a commit
that referenced
this pull request
Oct 7, 2026
<!-- SPDX-License-Identifier: CC-BY-SA-4.0 Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk> --> ## Summary This PR is a rescue of the D37 phase-zero recovery commit `632b54a` (2026-08-24), rebuilt as the single commit `d19776e` on `main` (the original commit left the branch so GitGuardian no longer sees its test-canary password; kept locally in `refs/rescued/pr596/`). `main` had independently landed most of the original work, so every one of the 33 conflicts resolves to `main`'s version: - the pin, `actions.lock` and permissions edits (#550–#566, #594); - the `fixer.rs` restoration. At the old base that file was a 14-line malformed patch fragment; `76ac79d` onward restored it; - the `hypatia.rs` `?` refactor; - the `6a2/` → `descriptiles/` move. A2ML is retired, so it is not re-homed; - the echidnabot `api.adoc` deletion (#586). Net change against `main`, 3 files: 1. **`repo-integrity-guard.yml`**: a new step, *Source files must not be patch fragments*. It fails when a tracked `*.rs/ex/exs/res/js/ts/py/sh` file starts with `@@ `, `*** Begin Patch` or `diff --git`. That is exactly how `fixer.rs` was broken. 2. **`.gitignore`**: ignores `.claude/worktrees/`, so an agent worktree can't be committed as a gitlink again. That had happened with `actions-policy`, which `main` has since dropped. 3. **`SECURITY.md`**: adds reporting expectations (acknowledgement within 48 hours, assessment within 7 days, 90-day coordinated disclosure), a supported-versions statement and a safe-harbour clause. It keeps `main`'s pointer to `SECURITY.adoc`, which has none of these. Closes: none ## Type of change - [ ] 🐛 Bug fix (non-breaking change that fixes an issue). The breakage is already fixed on `main`. - [ ] ✨ New feature (non-breaking change that adds functionality) - [ ] 💥 Breaking change (would change existing behaviour) - [x] 🕳️ Soundness fix (fixes a checker/proof false-negative). The integrity guard did not catch a source file that was a patch fragment. - [x] 📖 Documentation (`SECURITY.md`) - [ ] 🧹 Refactor / tech debt (behaviour-preserving) - [ ] ⚡ Performance - [x] 🔧 Build / CI / tooling ## 📌 New pins Head SHA: **`d19776e`**. This PR adds or changes no pins. Every `uses:` ref and `actions.lock` entry is `main`'s, byte for byte. ## How has this been verified? - `git diff --stat origin/main d19776e` shows 3 files changed, +41/−10, and nothing else. - I ran the new guard's script locally on the merged tree: rc=0, no findings. - Positive control: I planted `planted_frag.rs` starting with `@@ -1,2 +1,2 @@` and staged it with intent-to-add. The guard reported `::error file=planted_frag.rs::Source file begins with patch syntax` with rc=1. The planted file was then removed. - `actionlint .github/workflows/repo-integrity-guard.yml` was clean. - `grep` of `SECURITY.adoc` for hour/day/harbour/disclosure/acknowledge found nothing, so the `SECURITY.md` additions are not duplicates. ## Checklist - [x] My commits are **signed** (`git commit -S`). `d19776e` shows `G`. - [ ] I ran the project's own checks/tests locally and they pass. No Rust source changed against `main`. The repo's CI on `d19776e` is the check, and I ran the guard step locally (above). - [x] New files carry the correct `SPDX-License-Identifier`. There are no new files; `SECURITY.md` keeps its existing `MPL-2.0` header. - [x] Docs are updated, and no public claim now overstates what the code does. - [x] I have not introduced a soundness hole. The guard only adds a failure path. ## Notes for reviewers - The guard checks only the *first non-blank line* of each file. A fragment that is spliced into the middle of a file is out of its scope. - The `SECURITY.md` response-time commitments are the owner's text from `632b54a`, kept verbatim. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_014BxjiTAaTZCHVWn2U5NWhL Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 8, 2026
Closed
hyperpolymath
added a commit
that referenced
this pull request
Oct 8, 2026
## Summary This relocks `hyperpolymath/smtp-notify-action` at **v0.5.0** in `.github/workflows/actions.lock`. Dependabot #595 (`3d9d8bc`) bumped the action from v0.3.0 to v0.5.0 in `push-email-notify.yml` but did not regenerate the lock. Since then three checks have failed on `main`: - `actions.lock is in sync with the workflow YAML` - `governance / Actions lockfile verify` - `scorecard / Run Scorecard` The lock was regenerated with the estate tool, `hyperpolymath/standards` `scripts/update-actions-lock.sh` (standards `origin/main` @ `900c42c7`, `gh-actions-lock` v0.1.6), not edited by hand. The diff is 4 lines: - the `push-email-notify.yml` workflow key now lists `@v0.5.0`; - the `@v0.3.0` dependency record is replaced by `@v0.5.0`, resolved to its **commit**. No workflow file changed, so no `uses:` line was rewritten. Closes #604 ## Type of change - [x] 🐛 Bug fix: a lockfile desync on `main` that turns three checks red. - [ ] ✨ New feature: not applicable. - [ ] 💥 Breaking change: none. The workflow already uses v0.5.0; only the lock catches up. - [ ] 🕳️ Soundness fix: not applicable. - [ ] 📖 Documentation: no docs change. - [ ] 🧹 Refactor / tech debt: not applicable. - [ ] ⚡ Performance: not applicable. - [x] 🔧 Build / CI / tooling: `actions.lock` regeneration. ## 📌 New pins - **PR head SHA: `fd91919a269976cbb15f6e975dcc1eacd1842e34`** - **`actions.lock`: `hyperpolymath/smtp-notify-action@v0.5.0` → commit `c1c9fa07992a02c1fd3d67a0dc1b08cccb852aef`**. That is `refs/tags/v0.5.0^{}`, the peeled commit. The annotated tag object is `c6a2a6dc…`, and the lock does not use it (the #594 class). - **Removed: `hyperpolymath/smtp-notify-action@v0.3.0` (`22e7bdb3…`).** - No workflow `uses:` lines, lockfile records or container digests change beyond these. - No transitive entries are needed: `action.yml` at `c1c9fa07` is `using: 'composite'` with no `uses:` of its own. ## How has this been verified? All commands were run in the PR worktree at the head above: - `scripts/check-lock-sync.sh` printed "actions.lock is in sync and transitively closed … (0 dangling edges)" and exited **0**. - **Positive control:** the same script run on an `origin/main` (`f17965b`) export exited **1**, printing exactly #604's two lines: `step-level refs missing from the lockfile: hyperpolymath/smtp-notify-action@v0.5.0` and `stale lockfile entries, no uses: references them: hyperpolymath/smtp-notify-action@v0.3.0`. So the pass above is not vacuous. - `update-actions-lock.sh --verify-local` exited **0**. Afterwards, `git status --short` lists only `.github/workflows/actions.lock`, so the verifier mutated no workflow. - `git ls-remote https://github.com/hyperpolymath/smtp-notify-action 'refs/tags/v0.5.0*'` confirms that the recorded SHA is the peeled commit. - `git log -1 --show-signature` reports a good ED25519 signature, as `required_signatures` on `main` needs. - **Not run locally:** Scorecard's reconciliation and `governance / Actions lockfile verify` run only in CI. Their results on this head are the evidence for those two acceptance items. ## Checklist - [x] My commits are **signed**: SSH ED25519, verified locally. - [x] I ran the project's own checks locally and they pass: `check-lock-sync.sh` and the estate `--verify-local`, as above. - [x] New files carry the correct `SPDX-License-Identifier`: no new files. `actions.lock` is machine-generated ("Do not edit by hand") and carries no header, as before. - [x] Docs are updated, and no public claim now overstates what the code does: no doc describes the lock contents. - [x] I have not introduced a soundness hole. The pin is to an immutable commit, and no check was muted, demoted or set `continue-on-error`. ## Notes for reviewers - This branch supersedes nothing that was pushed. A local, unpushed branch `fix/actions-lock-desync` relocks v0.3.0 and is stale; it is being triaged separately and has no effect on this PR. ### Deferred red checks (not required; also red on `main`) - `Codeac analyze results` (legacy status): deferred to #590. The service cannot analyse the repo, and this PR doesn't change that. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_015bTuGfwCcvjrmNFejydTML Co-authored-by: Claude Opus 5.5 <noreply@anthropic.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.
Summary
Fixes the red
scorecardcheck onmain(dcfcdc4). The stepgh actions-lock --verifyreported an unreachable pin because the lock entry forhaskell-actions/setup@v2.12.1recorded the SHA of the annotated tag object (0f7370cc…) instead of the commit the tag points to (0f8e8c99…). This PR re-points that one entry to the commit. Theuses:line incasket-pages.ymlis the taghaskell-actions/setup@v2.12.1, not a SHA, so it needs no change. No other file in.github/mentions0f7370cc.Red checks addressed:
✗ Unreachable pin haskell-actions/setup@v2.12.1 … .github/workflows/casket-pages.yml("1 of 24 workflows failed verification"). With the commit recorded, the pin is reachable.Not addressed here (owner items, no code change possible):
Closes: no issue; found by the 2026-10-06 red-CI census.
Type of change
📌 New pins
Head SHA: 2afb665
.github/workflows/actions.lock,haskell-actions/setup@v2.12.1: commit0f7370ccbc65f22514ec3e094f6601b8d61fbbf7(tag object) →0f8e8c99d88aeb3fbfd523f1ef2c6f762d10d64d(commit, tagv2.12.1). I checked it withgh api repos/haskell-actions/setup/git/commits/0f8e8c99d88aeb3fbfd523f1ef2c6f762d10d64d, which returned 200. The owner and repo ids are unchanged.uses:lines changed.How has this been verified?
gh actions-lock --verify(v0.1.6) onorigin/mainprinted1 of 24 workflows failed verificationand✗ Unreachable pin haskell-actions/setup@v2.12.1. On this branch it prints onlyScanning 24 workflows, with no failures. The run on main is the planted positive: it shows the verifier can fail on this lock.gh api repos/haskell-actions/setup/git/tags/0f7370cc… -q .objectconfirmed that0f7370ccis a tag object whose target is commit0f8e8c99.grep -rn 0f7370cc .githubon this branch finds nothing.Checklist
git commit -S).git log --format=%G?showsG.gh actions-lock --verify, shown above. The repo has no local hooks, and this change touches no code.SPDX-License-Identifier: not applicable, no new files. The one edited file keeps its existing header.Notes for reviewers
The diff is one line. GitHub enforces
actions.lockat workflow startup, so a wrong commit here fails verification without any code change. The Codeac and mirror-* reds stay as owner items.🤖 Generated with Claude Code
https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm