Cloonar/coding-lab

Fork 0

chore(deps): Go module updates — x/text advisory GO-2026-5970, sqlite 1.55.0 (+libc lockstep), client_golang 1.24.1, yaml 2.4.4, goose 3.27.3 [schedule: Daily agent update check] #250

New issue

Open

opened 2026-07-31 04:09:30 +02:00 by dominik.polakovics · 2 comments

dominik.polakovics commented

2026-07-31 04:09:30 +02:00

Owner

Goal

Bring the five stale Go module pins in go.mod up to current. One of them closes a security advisory that our pinned version is inside; the rest are routine. All five are low-risk — none of the reviewed changelog entries touches an API this repo calls — but one of them (modernc.org/sqlite) has a hard lockstep requirement that will silently break the build if missed.

Everything below was checked against the upstream changelogs on 2026-07-31; the "does it break us" verdicts are stated per module with the reasoning, so you can re-check rather than take them on faith.

Evidence — what is behind

Module	`go.mod`	Latest	Kind
`golang.org/x/text` (indirect)	`v0.38.0`	`v0.40.0`	advisory
`modernc.org/sqlite`	`v1.53.0`	`v1.55.0`	minor ×2
`modernc.org/libc` (indirect)	`v1.73.4`	`v1.74.1`	lockstep with sqlite
`github.com/prometheus/client_golang`	`v1.23.2`	`v1.24.1`	minor + patch
`go.yaml.in/yaml/v2`	`v2.4.2`	`v2.4.4`	patch ×2
`github.com/pressly/goose/v3`	`v3.27.2`	`v3.27.3`	patch

Already current, do not touch: github.com/jackc/pgx/v5 v5.10.0, github.com/SherClockHolmes/webpush-go v1.4.0, github.com/prometheus/client_model v0.6.2, golang.org/x/crypto v0.52.0, golang.org/x/sys v0.47.0, golang.org/x/term v0.45.0.

Security

One advisory reaches a version we pin: GO-2026-5970.

GO-2026-5970  Infinite loop on invalid input in golang.org/x/text
  golang.org/x/text  introduced: 0  fixed: 0.39.0
  affected package: golang.org/x/text/unicode/norm

We pin golang.org/x/text v0.38.0 (go.mod, indirect block) — inside the affected range. Reachability was not verified (this investigation ran in an environment with no Go toolchain, so no govulncheck). x/text arrives only transitively; nothing under internal/ or cmd/ imports it directly. So this may well be unreachable in practice — but the fix is a one-line pin move, so bump it and let govulncheck say so definitively.

Deliberately not a reason to bump — stated so nobody re-derives it: golang.org/x/crypto looks alarming in the vulnerability database (14 advisories in 2026 alone: GO-2026-5005, 5006, 5013–5021, 5023, 5033). Every one of them is fixed in v0.52.0, which is exactly what we already pin, and every one is in golang.org/x/crypto/ssh* — this repo imports only golang.org/x/crypto/argon2 (internal/httpapi/password.go:11). The one still-open advisory, GO-2026-5932, is the unmaintained x/crypto/openpgp package, which we do not import. x/crypto needs no bump. Same story for golang.org/x/sys (GO-2026-5024 fixed in v0.44.0, we are on v0.47.0) and pgx/v5 (GO-2026-5004 fixed in 5.9.2, GO-2026-4771/4772 fixed in 5.9.0, we are on v5.10.0).

What changed, per module, and whether it breaks us

`modernc.org/sqlite` v1.53.0 → v1.55.0 — read this one carefully

Hard requirement, stated by upstream in its own changelog: "downstream modules must pin the exact same modernc.org/libc version this module's go.mod pins." sqlite v1.55.0 pins modernc.org/libc v1.74.1 (verified from https://proxy.golang.org/modernc.org/sqlite/@v/v1.55.0.mod). We currently carry modernc.org/libc v1.73.4. Both lines must move together. Do not independently bump libc to v1.74.4 (its own latest) — match what sqlite v1.55.0 pins. go mod tidy should do the right thing; verify the resulting go.mod line reads modernc.org/libc v1.74.1.

v1.54.0 — upgrades the embedded engine to SQLite 3.53.3. Adds an opt-in _texttotime DSN parameter; without it, behavior is byte-for-byte unchanged.
v1.55.0 — adds mattn/go-sqlite3-compatible shorthand DSN keys (_busy_timeout, _fk, _journal_mode, _synchronous, _auto_vacuum, _query_only). Upstream flags this as a real behavior change: those keys were previously ignored, and now they take effect, and an unrecognized value now fails the connection.
Does it break us? No — and here is the check. Our DSN recipe is pinned at internal/store/store.go:83-86:
```
"?_pragma=foreign_keys(1)&_pragma=busy_timeout(5000)&_pragma=journal_mode(WAL)&_txlock=immediate"
```
We use the _pragma=name(value) form and _txlock, not the mattn shorthand keys, so none of the newly-honored keys appear in our DSN. The second v1.55.0 change ("validate every DSN query parameter before applying any of them") does cover the pre-existing _txlock, but immediate remains a valid value. Re-read store.go when you do this and confirm the DSN recipe has not drifted from the quote above.
Note: upstream's changelog on master already documents a v1.56.0 (2026-07-30, adds NewConnector), but it is not yet on the Go module proxy (https://proxy.golang.org/modernc.org/sqlite/@v/list tops out at v1.55.0 as of 2026-07-31). Target v1.55.0; if v1.56.0 has published by the time you run this, taking it instead is fine — it is additive and its libc pin must be re-checked the same way.

`github.com/prometheus/client_golang` v1.23.2 → v1.24.1

v1.24.0 [CHANGE] minimum Go is now 1.25. We declare go 1.26 (go.mod:3) — fine.
v1.24.0 [CHANGE] name validation always uses the UTF-8 scheme; code that set model.NameValidationScheme = LegacyValidation loses legacy enforcement. We never set it (no match for NameValidationScheme anywhere under internal/) — fine.
v1.24.0 [CHANGE] api/prometheus/v1 signature changes (Rules, LabelNames) and exp/api/remote reshaping. We import none of those packages — we use prometheus, promhttp, and collectors only (internal/metrics/metrics.go, internal/metrics/lab.go) — fine.
v1.24.0 [FEATURE] new Go 1.26 runtime metrics, WithUnit option, Desc.Err(). Additive.
v1.24.1 [BUGFIX] promhttp: fix panic on requests with a nil URL (#2065). We serve promhttp — a straight robustness win.
internal/metrics/metrics_test.go:170 asserts the presence of lab_http_requests_total, lab_http_request_duration_seconds, and go_goroutines. All three survive; if that assertion fails, treat it as a real finding and report it rather than loosening the test.

`golang.org/x/text` v0.38.0 → v0.40.0 — the advisory fix (see Security above). Indirect only.

`go.yaml.in/yaml/v2` v2.4.2 → v2.4.4 — patch releases on the drop-in `gopkg.in/yaml.v2` replacement. Single call site: `internal/seeder/skillsindex.go:8`.

`github.com/pressly/goose/v3` v3.27.2 → v3.27.3 — upstream release notes read, in full: "### Changed — Various dependency upgrades". No API surface change. Migration runner + `migrations/`.

Scope

go.mod, go.sum — the six lines above (five direct/indirect targets plus whatever go mod tidy pulls behind them).
nix/package.nix:56 — vendorHash. This is the trap. Both Go derivations share one goModules fetch (nix/package.nix:55), and the hash is hard-coded:
```
vendorHash = "sha256-hOPrF9pvuxt4r29yoUo/Uy6G7FbCOyxmFPqDDXuEbnA=";
```
Any go.sum change invalidates it and the hermetic nix gate (.forgejo/workflows/ci-nix.yml) fails with a fixed-output-derivation hash mismatch. Set it to lib.fakeHash, run the build, and paste the got: hash from the error. This must land in the same commit as the go.mod change.
No production code changes are expected. If you need one, that is a finding — report it here.

How to verify

go mod tidy
grep -E 'modernc.org/(sqlite|libc)|golang.org/x/text' go.mod   # sqlite v1.55.0, libc v1.74.1, text v0.40.0
go build ./...
go test ./...                       # the store suite exercises the pinned SQLite DSN recipe
golangci-lint run                   # `make lint`
go run golang.org/x/vuln/cmd/govulncheck@latest ./...   # must be clean; specifically confirms GO-2026-5970 is gone
nix flake check                     # the hermetic gate — this is what catches a stale vendorHash

make test and make lint are the Makefile equivalents of the middle two.

Done means

All six pins moved, go mod tidy clean, go.sum regenerated.
modernc.org/libc is exactly the version modernc.org/sqlite v1.55.0 pins (v1.74.1), not its own latest.
nix/package.nix vendorHash regenerated in the same commit.
go build ./..., go test ./..., golangci-lint run all green.
govulncheck ./... reports no findings — in particular no GO-2026-5970.
nix flake check passes (proves the vendorHash is right).
The store suite passes unchanged — the pinned SQLite DSN recipe in internal/store/store.go is not edited as part of this.
PR body says Closes #<this issue>.

Out of scope

golang.org/x/crypto, golang.org/x/sys, golang.org/x/term, pgx/v5, webpush-go, client_model — all already current; leave them alone (rationale under Security above).
The Go language pin (go 1.26) and the nixpkgs flake input. Both current enough; flake.lock was locked 2026-07-05 and docs/ops.md records the nixpkgs pin deliberately (it must ship go_1_26) — moving it is a separate, ops-facing decision.
Web/npm dependencies — separate issue.

Filed by the Daily agent update check schedule, 2026-07-31. Versions from proxy.golang.org/<module>/@latest; advisory data from vuln.go.dev; changelogs from each project's own release notes.

## Goal Bring the five stale Go module pins in `go.mod` up to current. One of them closes a security advisory that our pinned version is inside; the rest are routine. All five are low-risk — none of the reviewed changelog entries touches an API this repo calls — but **one of them (`modernc.org/sqlite`) has a hard lockstep requirement** that will silently break the build if missed. Everything below was checked against the upstream changelogs on 2026-07-31; the "does it break us" verdicts are stated per module with the reasoning, so you can re-check rather than take them on faith. ## Evidence — what is behind | Module | `go.mod` | Latest | Kind | |---|---|---|---| | `golang.org/x/text` (indirect) | `v0.38.0` | `v0.40.0` | **advisory** | | `modernc.org/sqlite` | `v1.53.0` | `v1.55.0` | minor ×2 | | `modernc.org/libc` (indirect) | `v1.73.4` | `v1.74.1` | **lockstep with sqlite** | | `github.com/prometheus/client_golang` | `v1.23.2` | `v1.24.1` | minor + patch | | `go.yaml.in/yaml/v2` | `v2.4.2` | `v2.4.4` | patch ×2 | | `github.com/pressly/goose/v3` | `v3.27.2` | `v3.27.3` | patch | Already current, do **not** touch: `github.com/jackc/pgx/v5 v5.10.0`, `github.com/SherClockHolmes/webpush-go v1.4.0`, `github.com/prometheus/client_model v0.6.2`, `golang.org/x/crypto v0.52.0`, `golang.org/x/sys v0.47.0`, `golang.org/x/term v0.45.0`. ## Security **One advisory reaches a version we pin: `GO-2026-5970`.** ``` GO-2026-5970 Infinite loop on invalid input in golang.org/x/text golang.org/x/text introduced: 0 fixed: 0.39.0 affected package: golang.org/x/text/unicode/norm ``` We pin `golang.org/x/text v0.38.0` (`go.mod`, indirect block) — inside the affected range. **Reachability was not verified** (this investigation ran in an environment with no Go toolchain, so no `govulncheck`). `x/text` arrives only transitively; nothing under `internal/` or `cmd/` imports it directly. So this may well be unreachable in practice — but the fix is a one-line pin move, so bump it and let `govulncheck` say so definitively. **Deliberately not a reason to bump — stated so nobody re-derives it:** `golang.org/x/crypto` looks alarming in the vulnerability database (14 advisories in 2026 alone: `GO-2026-5005`, `5006`, `5013`–`5021`, `5023`, `5033`). Every one of them is **fixed in `v0.52.0`, which is exactly what we already pin**, and every one is in `golang.org/x/crypto/ssh*` — this repo imports only `golang.org/x/crypto/argon2` (`internal/httpapi/password.go:11`). The one still-open advisory, `GO-2026-5932`, is the unmaintained `x/crypto/openpgp` package, which we do not import. **`x/crypto` needs no bump.** Same story for `golang.org/x/sys` (`GO-2026-5024` fixed in `v0.44.0`, we are on `v0.47.0`) and `pgx/v5` (`GO-2026-5004` fixed in `5.9.2`, `GO-2026-4771`/`4772` fixed in `5.9.0`, we are on `v5.10.0`). ## What changed, per module, and whether it breaks us ### `modernc.org/sqlite` v1.53.0 → v1.55.0 — **read this one carefully** **Hard requirement, stated by upstream in its own changelog:** *"downstream modules must pin the exact same `modernc.org/libc` version this module's `go.mod` pins."* `sqlite v1.55.0` pins `modernc.org/libc v1.74.1` (verified from `https://proxy.golang.org/modernc.org/sqlite/@v/v1.55.0.mod`). We currently carry `modernc.org/libc v1.73.4`. **Both lines must move together.** Do not independently bump `libc` to `v1.74.4` (its own latest) — match what `sqlite v1.55.0` pins. `go mod tidy` should do the right thing; verify the resulting `go.mod` line reads `modernc.org/libc v1.74.1`. - **v1.54.0** — upgrades the embedded engine to SQLite 3.53.3. Adds an opt-in `_texttotime` DSN parameter; without it, behavior is byte-for-byte unchanged. - **v1.55.0** — adds `mattn/go-sqlite3`-compatible shorthand DSN keys (`_busy_timeout`, `_fk`, `_journal_mode`, `_synchronous`, `_auto_vacuum`, `_query_only`). Upstream flags this as a real behavior change: those keys were previously *ignored*, and now they take effect, and an unrecognized value now **fails the connection**. - **Does it break us? No — and here is the check.** Our DSN recipe is pinned at `internal/store/store.go:83-86`: ```go "?_pragma=foreign_keys(1)&_pragma=busy_timeout(5000)&_pragma=journal_mode(WAL)&_txlock=immediate" ``` We use the `_pragma=name(value)` form and `_txlock`, **not** the mattn shorthand keys, so none of the newly-honored keys appear in our DSN. The second v1.55.0 change ("validate every DSN query parameter before applying any of them") does cover the pre-existing `_txlock`, but `immediate` remains a valid value. Re-read `store.go` when you do this and confirm the DSN recipe has not drifted from the quote above. - Note: upstream's changelog on `master` already documents a **v1.56.0** (2026-07-30, adds `NewConnector`), but it is **not yet on the Go module proxy** (`https://proxy.golang.org/modernc.org/sqlite/@v/list` tops out at `v1.55.0` as of 2026-07-31). Target `v1.55.0`; if `v1.56.0` has published by the time you run this, taking it instead is fine — it is additive and its libc pin must be re-checked the same way. ### `github.com/prometheus/client_golang` v1.23.2 → v1.24.1 - **v1.24.0 [CHANGE]** minimum Go is now 1.25. We declare `go 1.26` (`go.mod:3`) — fine. - **v1.24.0 [CHANGE]** name validation always uses the UTF-8 scheme; code that set `model.NameValidationScheme = LegacyValidation` loses legacy enforcement. **We never set it** (no match for `NameValidationScheme` anywhere under `internal/`) — fine. - **v1.24.0 [CHANGE]** `api/prometheus/v1` signature changes (`Rules`, `LabelNames`) and `exp/api/remote` reshaping. **We import none of those packages** — we use `prometheus`, `promhttp`, and `collectors` only (`internal/metrics/metrics.go`, `internal/metrics/lab.go`) — fine. - **v1.24.0 [FEATURE]** new Go 1.26 runtime metrics, `WithUnit` option, `Desc.Err()`. Additive. - **v1.24.1 [BUGFIX]** `promhttp`: fix panic on requests with a nil URL (#2065). We serve `promhttp` — a straight robustness win. - `internal/metrics/metrics_test.go:170` asserts the presence of `lab_http_requests_total`, `lab_http_request_duration_seconds`, and `go_goroutines`. All three survive; if that assertion fails, treat it as a real finding and report it rather than loosening the test. ### `golang.org/x/text` v0.38.0 → v0.40.0 — the advisory fix (see Security above). Indirect only. ### `go.yaml.in/yaml/v2` v2.4.2 → v2.4.4 — patch releases on the drop-in `gopkg.in/yaml.v2` replacement. Single call site: `internal/seeder/skillsindex.go:8`. ### `github.com/pressly/goose/v3` v3.27.2 → v3.27.3 — upstream release notes read, in full: *"### Changed — Various dependency upgrades"*. No API surface change. Migration runner + `migrations/`. ## Scope - `go.mod`, `go.sum` — the six lines above (five direct/indirect targets plus whatever `go mod tidy` pulls behind them). - **`nix/package.nix:56` — `vendorHash`.** This is the trap. Both Go derivations share one `goModules` fetch (`nix/package.nix:55`), and the hash is hard-coded: ```nix vendorHash = "sha256-hOPrF9pvuxt4r29yoUo/Uy6G7FbCOyxmFPqDDXuEbnA="; ``` Any `go.sum` change invalidates it and the hermetic nix gate (`.forgejo/workflows/ci-nix.yml`) fails with a fixed-output-derivation hash mismatch. Set it to `lib.fakeHash`, run the build, and paste the `got:` hash from the error. **This must land in the same commit as the `go.mod` change.** - No production code changes are expected. If you need one, that is a finding — report it here. ## How to verify ```sh go mod tidy grep -E 'modernc.org/(sqlite|libc)|golang.org/x/text' go.mod # sqlite v1.55.0, libc v1.74.1, text v0.40.0 go build ./... go test ./... # the store suite exercises the pinned SQLite DSN recipe golangci-lint run # `make lint` go run golang.org/x/vuln/cmd/govulncheck@latest ./... # must be clean; specifically confirms GO-2026-5970 is gone nix flake check # the hermetic gate — this is what catches a stale vendorHash ``` `make test` and `make lint` are the Makefile equivalents of the middle two. ## Done means - [ ] All six pins moved, `go mod tidy` clean, `go.sum` regenerated. - [ ] `modernc.org/libc` is exactly the version `modernc.org/sqlite v1.55.0` pins (`v1.74.1`), not its own latest. - [ ] `nix/package.nix` `vendorHash` regenerated in the same commit. - [ ] `go build ./...`, `go test ./...`, `golangci-lint run` all green. - [ ] `govulncheck ./...` reports no findings — in particular no `GO-2026-5970`. - [ ] `nix flake check` passes (proves the vendorHash is right). - [ ] The store suite passes unchanged — the pinned SQLite DSN recipe in `internal/store/store.go` is **not** edited as part of this. - [ ] PR body says `Closes #<this issue>`. ## Out of scope - `golang.org/x/crypto`, `golang.org/x/sys`, `golang.org/x/term`, `pgx/v5`, `webpush-go`, `client_model` — all already current; leave them alone (rationale under Security above). - The Go language pin (`go 1.26`) and the nixpkgs flake input. Both current enough; `flake.lock` was locked 2026-07-05 and `docs/ops.md` records the nixpkgs pin deliberately (it must ship `go_1_26`) — moving it is a separate, ops-facing decision. - Web/npm dependencies — separate issue. --- *Filed by the Daily agent update check schedule, 2026-07-31. Versions from `proxy.golang.org/<module>/@latest`; advisory data from `vuln.go.dev`; changelogs from each project's own release notes.*

dominik.polakovics added the

ready-for-agent

chore

labels

2026-07-31 04:09:30 +02:00

dominik.polakovics commented

2026-07-31 05:08:59 +02:00

Author

Owner

Finding: goose/v3 cannot move to v3.27.3 — blocked by the sqlite/libc lockstep. Left at v3.27.2.

Evidence (verified against proxy.golang.org during the run):

goose v3.27.3's own go.mod requires modernc.org/libc v1.74.3 // indirect (its v3.27.3 release — release notes: "Various dependency upgrades" — bumped its own sqlite to v1.54.0 and libc to v1.74.3).
modernc.org/libc v1.74.3 (and v1.74.2) are retracted upstream: "freeaddrinfo leaks a locked ___lock entry; deadlocks name resolution, fixed in v1.74.4".
modernc.org/sqlite v1.55.0 lockstep-pins libc v1.74.1 exactly.

So under MVS the six targets are mutually unsatisfiable: taking goose v3.27.3 forces libc to v1.74.3 (retracted, deadlock bug) or — if bumped past the retraction — v1.74.4, which violates the lockstep requirement this issue rightly flags as hard. go get confirms: goose/v3@v3.27.3 requires modernc.org/libc@v1.74.3, not modernc.org/libc@v1.74.1.

Decision: honor the lockstep (libc v1.74.1, sqlite v1.55.0) and keep goose at v3.27.2. goose v3.27.3 has no code changes, only the dependency bumps that create this very conflict, so nothing is lost. The goose bump unblocks when either (a) sqlite ships a release pinning libc ≥ v1.74.4 (the changelog's unpublished v1.56.0 is a candidate — re-check its libc pin), or (b) a later goose release lands on a lockstep-compatible libc. Suggest the daily schedule will simply pick it up then.

One more scope note: go get opportunistically moved golang.org/x/crypto v0.52.0 → v0.54.0 (v0.54.0 is now upstream latest, so the issue's "already current" table entry was stale by a hair). Nothing in the module graph requires > v0.52.0 and the issue says leave it alone, so it was reverted to v0.52.0. All 2026 x/crypto advisories remain fixed at that version; govulncheck is clean either way.

**Finding: `goose/v3` cannot move to v3.27.3 — blocked by the sqlite/libc lockstep. Left at v3.27.2.** Evidence (verified against proxy.golang.org during the run): - `goose v3.27.3`'s own go.mod requires `modernc.org/libc v1.74.3 // indirect` (its v3.27.3 release — release notes: *"Various dependency upgrades"* — bumped its own sqlite to v1.54.0 and libc to v1.74.3). - `modernc.org/libc v1.74.3` (and v1.74.2) are **retracted** upstream: *"freeaddrinfo leaks a locked ___lock entry; deadlocks name resolution, fixed in v1.74.4"*. - `modernc.org/sqlite v1.55.0` lockstep-pins `libc v1.74.1` exactly. So under MVS the six targets are mutually unsatisfiable: taking goose v3.27.3 forces libc to v1.74.3 (retracted, deadlock bug) or — if bumped past the retraction — v1.74.4, which violates the lockstep requirement this issue rightly flags as hard. `go get` confirms: `goose/v3@v3.27.3 requires modernc.org/libc@v1.74.3, not modernc.org/libc@v1.74.1`. Decision: honor the lockstep (libc **v1.74.1**, sqlite **v1.55.0**) and keep goose at **v3.27.2**. goose v3.27.3 has no code changes, only the dependency bumps that create this very conflict, so nothing is lost. The goose bump unblocks when either (a) sqlite ships a release pinning libc ≥ v1.74.4 (the changelog's unpublished v1.56.0 is a candidate — re-check its libc pin), or (b) a later goose release lands on a lockstep-compatible libc. Suggest the daily schedule will simply pick it up then. One more scope note: `go get` opportunistically moved `golang.org/x/crypto` v0.52.0 → v0.54.0 (v0.54.0 is now upstream latest, so the issue's "already current" table entry was stale by a hair). Nothing in the module graph requires > v0.52.0 and the issue says leave it alone, so it was reverted to **v0.52.0**. All 2026 x/crypto advisories remain fixed at that version; govulncheck is clean either way.

dominik.polakovics referenced this issue from a commit

2026-07-31 05:12:18 +02:00

chore(deps): x/text v0.40.0 (GO-2026-5970), sqlite v1.55.0 + libc v1.74.1 lockstep, client_golang v1.24.1, yaml v2.4.4

dominik.polakovics referenced this issue from a pull request that will close it,

2026-07-31 05:12:41 +02:00

chore(deps): Go module updates — x/text advisory GO-2026-5970, sqlite v1.55.0 + libc lockstep, client_golang v1.24.1, yaml v2.4.4 #253

dominik.polakovics commented

2026-08-01 04:08:41 +02:00

Author

Owner

Re-verified 2026-08-01 (Daily agent update check). The advisory driver and the sqlite/libc lockstep both stand unchanged — but the "already current, do not touch" list has two errors. Two more pins are stale.

Correction 1 — `golang.org/x/crypto` is NOT current

The body lists golang.org/x/crypto v0.52.0 under "Already current, do not touch". It is not:

$ curl -s https://proxy.golang.org/golang.org/x/crypto/@v/list | sort -V | tail -5
v0.50.0 v0.51.0 v0.52.0 v0.53.0 v0.54.0
$ curl -s https://proxy.golang.org/golang.org/x/crypto/@latest
v0.54.0   (2026-07-08)

go.mod:12 pins v0.52.0, so we are two releases behind. The security reasoning in the body is still correct and needs no revision — every advisory listed there is fixed in v0.52.0, and nothing new has landed (see re-check below). Only the "already current" claim is wrong.

What is in v0.52.0 → v0.54.0 (from the golang/crypto commit log, 2026-06-02 .. 2026-07-23): ~35 commits, of which all but two are under ssh/, ssh/agent, ssh/knownhosts, ssh/test, acme/, x509roots/fallback, ocsp/, pkcs12/, or openpgp/. This repo imports exactly one x/crypto package — golang.org/x/crypto/argon2 (internal/httpapi/password.go:11). The only argon2 commit in the window is:

0b316e7ee409  2026-06-18  argon2: update RFC 9106 parameter recommendations
  "Update the IDKey example to use RFC 9106's first recommended Argon2id
   option and clarify the relationship between the first and second
   recommended options."   (golang/go#79823)

That is a doc-comment change only — no exported signature, no default, no behavior. internal/httpapi/password.go:23-29 pins the RFC 9106 second recommended set (time=3, memory=64MiB, threads=4, keyLen=32, saltLen=16) as explicit constants, so the revised example in upstream's docs does not reach us. Do not touch defaultArgonParams — it is a design §12 decision, not a copy of upstream's example.

So: bump golang.org/x/crypto v0.52.0 → v0.54.0 as routine hygiene, expect zero code impact, and leave password.go alone.

Correction 2 — `golang.org/x/sync` is stale and was omitted entirely

go.mod:38 pins golang.org/x/sync v0.21.0 // indirect; latest is v0.22.0. Not mentioned anywhere in the body. Indirect, low-risk, let go mod tidy carry it.

Re-confirmed, no change needed

GO-2026-5970 (x/text, fixed 0.39.0) is still the only advisory reaching any pin we carry. Checked the full vuln.go.dev module index for all 13 modules in our graph on 2026-08-01: no new advisory since this issue was filed. x/crypto's newest entries (GO-2026-5005/5006/5013–5021/5023/5033) are all fixed: 0.52.0; the one unfixed entry GO-2026-5932 is x/crypto/openpgp, which we do not import. x/sys GO-2026-5024 is fixed: 0.44.0 (we are on v0.47.0). The body's security section is accurate as written.
modernc.org/sqlite v1.56.0 is still NOT on the Go module proxy — the body flagged this as a thing to re-check:
```
$ curl -s https://proxy.golang.org/modernc.org/sqlite/@v/list | sort -V | tail -3
v1.53.0 v1.54.0 v1.55.0
```
v1.55.0 remains the target. The lockstep requirement is unchanged: it pins modernc.org/libc v1.74.1 exactly.
modernc.org/libc @latest is now v1.74.4 — consistent with the retraction note in the earlier comment (v1.74.2/v1.74.3 retracted). Do not take v1.74.4; take the v1.74.1 that sqlite v1.55.0 pins, exactly as the body says.
golang.org/x/term v0.45.0 and golang.org/x/sys v0.47.0 really are current — those two entries in the "do not touch" list are correct.
goose/v3 stays at v3.27.2, blocked by the libc lockstep for the reason given in the earlier comment. Unchanged.

Updated target table

Module	`go.mod`	Target	Note
`golang.org/x/text` (indirect)	v0.38.0	v0.40.0	advisory GO-2026-5970
`modernc.org/sqlite`	v1.53.0	v1.55.0	libc lockstep
`modernc.org/libc` (indirect)	v1.73.4	v1.74.1	exactly what sqlite v1.55.0 pins
`github.com/prometheus/client_golang`	v1.23.2	v1.24.1
`go.yaml.in/yaml/v2`	v2.4.2	v2.4.4
`golang.org/x/crypto`	v0.52.0	v0.54.0	new — see Correction 1
`golang.org/x/sync` (indirect)	v0.21.0	v0.22.0	new — see Correction 2
`github.com/pressly/goose/v3`	v3.27.2	stays	blocked, see earlier comment

Everything else in the body — the vendorHash trap at nix/package.nix:56, the DSN check at internal/store/store.go:83-86, the client_golang analysis, the verification commands, and the done-list — stands as written.

**Re-verified 2026-08-01 (Daily agent update check). The advisory driver and the sqlite/libc lockstep both stand unchanged — but the "already current, do not touch" list has two errors. Two more pins are stale.** ### Correction 1 — `golang.org/x/crypto` is NOT current The body lists `golang.org/x/crypto v0.52.0` under *"Already current, do not touch"*. It is not: ``` $ curl -s https://proxy.golang.org/golang.org/x/crypto/@v/list | sort -V | tail -5 v0.50.0 v0.51.0 v0.52.0 v0.53.0 v0.54.0 $ curl -s https://proxy.golang.org/golang.org/x/crypto/@latest v0.54.0 (2026-07-08) ``` `go.mod:12` pins `v0.52.0`, so we are two releases behind. **The security reasoning in the body is still correct and needs no revision** — every advisory listed there is fixed in v0.52.0, and nothing new has landed (see re-check below). Only the "already current" *claim* is wrong. What is in v0.52.0 → v0.54.0 (from the `golang/crypto` commit log, 2026-06-02 .. 2026-07-23): ~35 commits, of which all but two are under `ssh/`, `ssh/agent`, `ssh/knownhosts`, `ssh/test`, `acme/`, `x509roots/fallback`, `ocsp/`, `pkcs12/`, or `openpgp/`. **This repo imports exactly one `x/crypto` package — `golang.org/x/crypto/argon2` (`internal/httpapi/password.go:11`).** The only `argon2` commit in the window is: ``` 0b316e7ee409 2026-06-18 argon2: update RFC 9106 parameter recommendations "Update the IDKey example to use RFC 9106's first recommended Argon2id option and clarify the relationship between the first and second recommended options." (golang/go#79823) ``` That is a **doc-comment change only** — no exported signature, no default, no behavior. `internal/httpapi/password.go:23-29` pins the RFC 9106 *second* recommended set (`time=3, memory=64MiB, threads=4, keyLen=32, saltLen=16`) as explicit constants, so the revised example in upstream's docs does not reach us. **Do not touch `defaultArgonParams`** — it is a design §12 decision, not a copy of upstream's example. So: bump `golang.org/x/crypto v0.52.0 → v0.54.0` as routine hygiene, expect zero code impact, and leave `password.go` alone. ### Correction 2 — `golang.org/x/sync` is stale and was omitted entirely `go.mod:38` pins `golang.org/x/sync v0.21.0 // indirect`; latest is **v0.22.0**. Not mentioned anywhere in the body. Indirect, low-risk, let `go mod tidy` carry it. ### Re-confirmed, no change needed - **`GO-2026-5970` (x/text, fixed 0.39.0) is still the only advisory reaching any pin we carry.** Checked the full `vuln.go.dev` module index for all 13 modules in our graph on 2026-08-01: no new advisory since this issue was filed. `x/crypto`'s newest entries (`GO-2026-5005`/`5006`/`5013`–`5021`/`5023`/`5033`) are all `fixed: 0.52.0`; the one unfixed entry `GO-2026-5932` is `x/crypto/openpgp`, which we do not import. `x/sys` `GO-2026-5024` is `fixed: 0.44.0` (we are on v0.47.0). The body's security section is accurate as written. - **`modernc.org/sqlite v1.56.0` is still NOT on the Go module proxy** — the body flagged this as a thing to re-check: ``` $ curl -s https://proxy.golang.org/modernc.org/sqlite/@v/list | sort -V | tail -3 v1.53.0 v1.54.0 v1.55.0 ``` **`v1.55.0` remains the target.** The lockstep requirement is unchanged: it pins `modernc.org/libc v1.74.1` exactly. - `modernc.org/libc @latest` is now **v1.74.4** — consistent with the retraction note in the earlier comment (v1.74.2/v1.74.3 retracted). Do **not** take v1.74.4; take the `v1.74.1` that `sqlite v1.55.0` pins, exactly as the body says. - `golang.org/x/term v0.45.0` and `golang.org/x/sys v0.47.0` really are current — those two entries in the "do not touch" list are correct. - `goose/v3` stays at **v3.27.2**, blocked by the libc lockstep for the reason given in the earlier comment. Unchanged. ### Updated target table | Module | `go.mod` | Target | Note | |---|---|---|---| | `golang.org/x/text` (indirect) | v0.38.0 | **v0.40.0** | advisory GO-2026-5970 | | `modernc.org/sqlite` | v1.53.0 | **v1.55.0** | libc lockstep | | `modernc.org/libc` (indirect) | v1.73.4 | **v1.74.1** | exactly what sqlite v1.55.0 pins | | `github.com/prometheus/client_golang` | v1.23.2 | **v1.24.1** | | | `go.yaml.in/yaml/v2` | v2.4.2 | **v2.4.4** | | | `golang.org/x/crypto` | v0.52.0 | **v0.54.0** | *new — see Correction 1* | | `golang.org/x/sync` (indirect) | v0.21.0 | **v0.22.0** | *new — see Correction 2* | | `github.com/pressly/goose/v3` | v3.27.2 | *stays* | blocked, see earlier comment | Everything else in the body — the `vendorHash` trap at `nix/package.nix:56`, the DSN check at `internal/store/store.go:83-86`, the `client_golang` analysis, the verification commands, and the done-list — stands as written.

dominik.polakovics referenced this issue

2026-08-01 04:10:05 +02:00

chore(web): jsdom 29.1.1 → 30.0.1 — the only landable npm major (eslint 10 + TypeScript 7 are peer-blocked upstream) [schedule: Daily agent update check] #255