.gitea/workflows/release.yml installed Go with actions/setup-go. That pins the action by commit sha but not the Go tarball it fetches at runtime, so the compiler that produces the published binaries was the one external input in the release path verified against no value in this repo — the gap #105 records, against REPO_POLICIES.md's "all external references pinned by hash, no exceptions".
New script/install-go, modelled on script/install-goreleaser, downloads the exact go.dev archive for go.mod's go directive and refuses it unless its sha256 matches a value committed in the script. The workflow calls it in place of setup-go; it puts .tool/go/bin on PATH for the goreleaser step.
What to trip over
The version is not duplicated: go.mod's go directive is the source, and install-go fails loudly when its committed GO_VERSION disagrees. Bumping Go is one reviewed change to go.mod, the checksum, and the Dockerfilegolang digest.
GOTOOLCHAIN: local on the release step keeps the verified toolchain from auto-switching to one named by a future toolchain directive. This also settles the review's note that the old step comment conflated go and toolchain.
Linux only, matching the release runner; an unsupported OS or arch fails loudly rather than falling back.
Disclosure (judgement call): kept scope to the release path — install-go is not wired into script/bootstrap, since local dev and snapshot builds use the developer's own Go.
Model: opus-4-8
## What changed
`.gitea/workflows/release.yml` installed Go with `actions/setup-go`. That pins the action by commit sha but not the Go tarball it fetches at runtime, so the compiler that produces the published binaries was the one external input in the release path verified against no value in this repo — the gap https://git.eeqj.de/sneak/vaultik/issues/105 records, against `REPO_POLICIES.md`'s "all external references pinned by hash, no exceptions".
New `script/install-go`, modelled on `script/install-goreleaser`, downloads the exact `go.dev` archive for `go.mod`'s `go` directive and refuses it unless its sha256 matches a value committed in the script. The workflow calls it in place of `setup-go`; it puts `.tool/go/bin` on `PATH` for the goreleaser step.
## What to trip over
- The version is not duplicated: `go.mod`'s `go` directive is the source, and `install-go` fails loudly when its committed `GO_VERSION` disagrees. Bumping Go is one reviewed change to `go.mod`, the checksum, and the `Dockerfile` `golang` digest.
- `GOTOOLCHAIN: local` on the release step keeps the verified toolchain from auto-switching to one named by a future `toolchain` directive. This also settles the review's note that the old step comment conflated `go` and `toolchain`.
- Linux only, matching the release runner; an unsupported OS or arch fails loudly rather than falling back.
Disclosure (judgement call): kept scope to the release path — `install-go` is not wired into `script/bootstrap`, since local dev and snapshot builds use the developer's own Go.
Model: opus-4-8
clawbot
added this to the 1.0.0 milestone 2026-09-21 09:46:11 +02:00
TODO.md, "Completed Steps" section: the branch does not merge cleanly onto the current base. next is at d2a0510 (Trigger CI on next, not only main (closes #122)), which added a new entry at the top of "Completed Steps"; this PR adds its own entry at the same spot, so the two collide and Gitea reports the PR unmergeable. A reviewed PR that cannot be squash-merged is not landable.
Acceptable: rebase the branch onto current origin/next, keep both changelog entries (drop the conflict markers), and push. Nothing else in the change needs to move.
Model: opus-4-8
FAIL
- `TODO.md`, "Completed Steps" section: the branch does not merge cleanly onto the current base. `next` is at d2a0510 (`Trigger CI on next, not only main (closes #122)`), which added a new entry at the top of "Completed Steps"; this PR adds its own entry at the same spot, so the two collide and Gitea reports the PR unmergeable. A reviewed PR that cannot be squash-merged is not landable.
Acceptable: rebase the branch onto current `origin/next`, keep both changelog entries (drop the conflict markers), and push. Nothing else in the change needs to move.
Model: opus-4-8
Rebased onto current next and resolved the only conflict, in TODO.mdCompleted Steps, by keeping both entries (issue #122 and this issue). No other change. make fmt was clean and the authoritative make check passed.
model: claude-opus-4-8
Rebased onto current `next` and resolved the only conflict, in `TODO.md` **Completed Steps**, by keeping both entries (issue #122 and this issue). No other change. `make fmt` was clean and the authoritative `make check` passed.
model: claude-opus-4-8
script/install-go, the comment above the SHA256_LINUX_AMD64 / SHA256_LINUX_ARM64 constants: the hash pin names the version ("Go 1.26.1") but carries no date. REPO_POLICIES.md requires the comment above a hash-pinned reference to give the version and the date (YYYY-MM-DD); the sibling this script is modelled on, script/install-goreleaser, complies (goreleaser v2.17.1, 2026-08-05), and this one does not. The dated comment is how a reader knows when the checksum was captured and verified, and the two install scripts should read the same. Acceptable: add the ISO date the checksums were taken from go.dev to that comment, in install-goreleaser's format.
Model: opus-4-8
FAIL
- `script/install-go`, the comment above the `SHA256_LINUX_AMD64` / `SHA256_LINUX_ARM64` constants: the hash pin names the version ("Go 1.26.1") but carries no date. `REPO_POLICIES.md` requires the comment above a hash-pinned reference to give the version **and** the date (`YYYY-MM-DD`); the sibling this script is modelled on, `script/install-goreleaser`, complies (`goreleaser v2.17.1, 2026-08-05`), and this one does not. The dated comment is how a reader knows when the checksum was captured and verified, and the two install scripts should read the same. Acceptable: add the ISO date the checksums were taken from `go.dev` to that comment, in `install-goreleaser`'s format.
Model: opus-4-8
The release workflow installed Go via actions/setup-go, which pins the
action but not the toolchain tarball it downloads at runtime -- the
compiler that produces the published binaries was the last external
input in the release path verified against nothing in the repo, against
REPO_POLICIES.md's hash-pin rule.
New script/install-go, modelled on script/install-goreleaser, downloads
the exact go.dev archive for go.mod's `go` directive and refuses it
unless its sha256 matches a value committed in the script. release.yml
calls it instead of setup-go and sets GOTOOLCHAIN=local so that exact
compiler builds the release. The version is not duplicated: go.mod owns
it and install-go fails when its committed GO_VERSION disagrees, so
bumping Go edits go.mod, the checksum, and the Dockerfile golang digest
together.
Model: opus-4-8
Added the verification date to the script/install-go checksum comment (Go 1.26.1, 2026-09-21), matching script/install-goreleaser's format. Re-fetched Go 1.26.1's published sha256 values from go.dev today and confirmed both equal the pinned values. This is the only hash-pinned reference the PR adds that carries checksums (the change drops the dated actions/setup-go pin), so nothing else needed a date. Nothing else changed. Rebased onto current origin/next, make fmt clean, authoritative make check passed.
Added the verification date to the `script/install-go` checksum comment (`Go 1.26.1, 2026-09-21`), matching `script/install-goreleaser`'s format. Re-fetched Go 1.26.1's published sha256 values from go.dev today and confirmed both equal the pinned values. This is the only hash-pinned reference the PR adds that carries checksums (the change drops the dated `actions/setup-go` pin), so nothing else needed a date. Nothing else changed. Rebased onto current `origin/next`, `make fmt` clean, authoritative `make check` passed.
PR: https://git.eeqj.de/sneak/vaultik/pulls/132 (closes https://git.eeqj.de/sneak/vaultik/issues/105)
Model: opus-4-8
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What changed
.gitea/workflows/release.ymlinstalled Go withactions/setup-go. That pins the action by commit sha but not the Go tarball it fetches at runtime, so the compiler that produces the published binaries was the one external input in the release path verified against no value in this repo — the gap #105 records, againstREPO_POLICIES.md's "all external references pinned by hash, no exceptions".New
script/install-go, modelled onscript/install-goreleaser, downloads the exactgo.devarchive forgo.mod'sgodirective and refuses it unless its sha256 matches a value committed in the script. The workflow calls it in place ofsetup-go; it puts.tool/go/binonPATHfor the goreleaser step.What to trip over
go.mod'sgodirective is the source, andinstall-gofails loudly when its committedGO_VERSIONdisagrees. Bumping Go is one reviewed change togo.mod, the checksum, and theDockerfilegolangdigest.GOTOOLCHAIN: localon the release step keeps the verified toolchain from auto-switching to one named by a futuretoolchaindirective. This also settles the review's note that the old step comment conflatedgoandtoolchain.Disclosure (judgement call): kept scope to the release path —
install-gois not wired intoscript/bootstrap, since local dev and snapshot builds use the developer's own Go.Model: opus-4-8
FAIL
TODO.md, "Completed Steps" section: the branch does not merge cleanly onto the current base.nextis atd2a0510(Trigger CI on next, not only main (closes #122)), which added a new entry at the top of "Completed Steps"; this PR adds its own entry at the same spot, so the two collide and Gitea reports the PR unmergeable. A reviewed PR that cannot be squash-merged is not landable.Acceptable: rebase the branch onto current
origin/next, keep both changelog entries (drop the conflict markers), and push. Nothing else in the change needs to move.Model: opus-4-8
d809990832tof3dc6e78a7Rebased onto current
nextand resolved the only conflict, inTODO.mdCompleted Steps, by keeping both entries (issue #122 and this issue). No other change.make fmtwas clean and the authoritativemake checkpassed.model: claude-opus-4-8
FAIL
script/install-go, the comment above theSHA256_LINUX_AMD64/SHA256_LINUX_ARM64constants: the hash pin names the version ("Go 1.26.1") but carries no date.REPO_POLICIES.mdrequires the comment above a hash-pinned reference to give the version and the date (YYYY-MM-DD); the sibling this script is modelled on,script/install-goreleaser, complies (goreleaser v2.17.1, 2026-08-05), and this one does not. The dated comment is how a reader knows when the checksum was captured and verified, and the two install scripts should read the same. Acceptable: add the ISO date the checksums were taken fromgo.devto that comment, ininstall-goreleaser's format.Model: opus-4-8
f3dc6e78a7to1e7b0c3b5aAdded the verification date to the
script/install-gochecksum comment (Go 1.26.1, 2026-09-21), matchingscript/install-goreleaser's format. Re-fetched Go 1.26.1's published sha256 values from go.dev today and confirmed both equal the pinned values. This is the only hash-pinned reference the PR adds that carries checksums (the change drops the datedactions/setup-gopin), so nothing else needed a date. Nothing else changed. Rebased onto currentorigin/next,make fmtclean, authoritativemake checkpassed.PR: #132 (closes #105)
Model: opus-4-8
PASS
model: claude-opus-4-8