chore(deps): Go modules — sqlite 1.56.0 (corruption fix) + libc 1.74.4 lockstep, goose 3.27.3 unblocked, advisories GO-2026-5970 + GO-2025-3553 [schedule: Daily agent update check] #250
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Cloonar/coding-lab#250
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Bring the stale Go module pins in
go.modup to current. Two of them close security advisories that our pinned versions are inside; one of them (modernc.org/sqlite) closes a SQLite data-corruption bug; the rest are routine. None of the reviewed changelog entries touches an API this repo calls — butmodernc.org/sqlitehas a hard libc lockstep requirement that will silently break the build if missed.Everything below was checked against the upstream changelogs and
proxy.golang.orgon 2026-08-04; 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
go.modmodernc.org/sqlitev1.53.0v1.56.0modernc.org/libc(indirect)v1.73.4v1.74.4golang.org/x/text(indirect)v0.38.0v0.40.0github.com/golang-jwt/jwt/v5(indirect)v5.2.1v5.3.1github.com/pressly/goose/v3v3.27.2v3.27.3github.com/prometheus/client_golangv1.23.2v1.24.1github.com/prometheus/common(indirect)v0.66.1v0.70.1github.com/prometheus/procfs(indirect)v0.20.1v0.21.1go.yaml.in/yaml/v2v2.4.2v2.4.4golang.org/x/cryptov0.52.0v0.54.0go getgolang.org/x/sync(indirect)v0.21.0v0.22.0github.com/mattn/go-isatty(indirect)v0.0.21v0.0.24github.com/sethvargo/go-retry(indirect)v0.3.0v0.4.0Only
golang.org/x/cryptoneeds an explicitgo get. Everything else is carried by minimum-version selection once you bumpmodernc.org/sqlite,github.com/pressly/goose/v3andgithub.com/prometheus/client_golang— see "What MVS carries for free". Verify the resulting versions against this table either way.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/sys v0.47.0,golang.org/x/term v0.45.0,google.golang.org/protobuf v1.36.11,modernc.org/mathutil v1.7.1,modernc.org/memory v1.11.0,github.com/google/uuid v1.6.0,github.com/cespare/xxhash/v2 v2.3.0,github.com/dustin/go-humanize v1.0.1,github.com/ncruces/go-strftime v1.0.0,github.com/jackc/puddle/v2 v2.2.2,github.com/mfridman/interpolate v0.0.2,go.uber.org/multierr v1.11.0— all confirmed at upstream@lateston 2026-08-04.Security
Two advisories reach versions we pin, plus one data-corruption bug.
1.
GO-2026-5970—golang.org/x/textWe pin
golang.org/x/text v0.38.0(go.mod, indirect block) — inside the affected range. Reachability was not verified (this investigation ran without a Go toolchain, so nogovulncheck).x/textarrives only transitively; nothing underinternal/orcmd/imports it directly. So this may well be unreachable in practice — but the fix is a one-line pin move, so bump it and letgovulnchecksay so definitively.2.
GO-2025-3553—github.com/golang-jwt/jwt/v5go.modpinsgithub.com/golang-jwt/jwt/v5 v5.2.1in the indirect block — inside the affected range. It arrives viagithub.com/SherClockHolmes/webpush-go v1.4.0, whose owngo.modrequires exactlyv5.2.1.Expected reachability: none, but bump anyway. The advisory's affected symbol is
Parser.ParseUnverified. webpush-go only signs — its sole jwt call site isvapid.go:80,jwt.NewWithClaims(jwt.SigningMethodES256, …)for the VAPIDAuthorizationheader, whichinternal/push/sender.go:196drives throughwebpush.SendNotificationWithContext. Nothing in this repo or in webpush-go parses a JWT, sogovulncheck's symbol analysis should report it unreachable. Bump regardless: it is free (see below), and a version-range scanner will keep flaggingv5.2.1forever otherwise. Confirm withgovulncheckrather than trusting this paragraph.3. Not a CVE, but the strongest reason on this issue — the SQLite 3.53.3 journal-rollback corruption
Not in any advisory database (it is an upstream SQLite bug, patched downstream by
modernc.org/libsqlite3), but it is a silent database-corruption bug and it is the reason the sqlite target moved fromv1.55.0tov1.56.0. Full analysis in themodernc.org/sqlitesection below. The short version:v1.53.0embeds SQLite 3.53.2 — not affected.v1.54.0upgraded the engine to SQLite 3.53.3, which introduced the bug.v1.55.0still carries it.v1.56.0patches the amalgamation before transpiling — fixed.So the previously-specified target
v1.55.0would have moved us from a correct engine onto a knowingly-corrupting one, for no benefit. Takev1.56.0.Deliberately not a reason to bump — stated so nobody re-derives it:
golang.org/x/cryptolooks alarming in the vulnerability database (29 advisories, 14 of them in 2026:GO-2026-5005,5006,5013–5021,5023,5033). Every one of them is fixed inv0.52.0, which is what we already pin, and every one is ingolang.org/x/crypto/ssh*. This repo imports exactly onex/cryptopackage —golang.org/x/crypto/argon2(internal/httpapi/password.go:11). The one still-open advisory,GO-2026-5932, coversx/crypto/openpgp, which we do not import. Thex/cryptorow in the table above is hygiene, not security. Same story forgolang.org/x/sys(GO-2026-5024, fixedv0.44.0, we are onv0.47.0),pgx/v5(GO-2026-5004fixed5.9.2;GO-2026-4771/4772fixed5.9.0; we are onv5.10.0),google.golang.org/protobuf(GO-2024-2611fixed1.33.0, we are onv1.36.11) andprometheus/client_golang(GO-2022-0322fixed1.11.1).Full sweep, 2026-08-03, re-confirmed 2026-08-04: every one of the 34 modules in
go.modwas checked against the completevuln.go.devmodule index (not just the direct ones — that narrower check is what missedGO-2025-3553on the earlier passes). Only the seven modules listed above appear in the index at all, and onlyx/textandgolang-jwt/jwt/v5have an advisory whose affected range contains the version we pin.What MVS carries for free
Verified from the upstream
.modfiles on 2026-08-04.modernc.org/sqlite v1.56.0(https://proxy.golang.org/modernc.org/sqlite/@v/v1.56.0.mod) requires:github.com/pressly/goose/v3 v3.27.3(https://proxy.golang.org/github.com/pressly/goose/v3/@v/v3.27.3.mod) requires (relevant lines only):github.com/prometheus/client_golang v1.24.1requires:So the three bumps carry everything else in the target table — both advisories close as a side effect. Do not fight it, and do not assume it: check the resulting
go.modagainst the target table.Expect new
// indirectlines. From sqlite v1.56.0:github.com/google/pprof,modernc.org/fileutil. Fromclient_golang v1.24.1/prometheus/common v0.70.1:github.com/json-iterator/go,github.com/klauspost/compress,github.com/modern-go/concurrent,github.com/modern-go/reflect2,github.com/jpillora/backoff,github.com/mwitkow/go-conntrack,golang.org/x/net,golang.org/x/oauth2. Whichever of thosego mod tidydecides our build actually needs will appear in the indirect block. That is normal and is not a finding — but it enlarges thego.sumdiff, which is thevendorHashtrap below.What changed, per module, and whether it breaks us
modernc.org/sqlitev1.53.0 → v1.56.0 — read this one carefullyHard requirement, stated by upstream in its own changelog: "downstream modules must pin the exact same
modernc.org/libcversion this module'sgo.modpins" (GitLab issue #177).sqlite v1.56.0pinsmodernc.org/libc v1.74.4(verified from the.modabove). We currently carrymodernc.org/libc v1.73.4. Both lines must move together.v1.74.4also happens to belibc's own@latest, so for this bump — unlike the previous target — the two coincide. Verify the resultinggo.modline readsmodernc.org/libc v1.74.4.v1.54.0 — upgrades the embedded engine to SQLite 3.53.3. Adds an opt-in
_texttotimeDSN parameter; without it, behavior is byte-for-byte unchanged. This release also introduced the corruption bug below.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. Also: every DSN query parameter is now validated before any of them is applied, so a DSN with a bad later parameter no longer leaves the file half-converted.v1.56.0 — the data-corruption fix. Quoting upstream's changelog:
v1.56.0 also adds
NewConnector(additive; we do not use it) and regenerates thelinux/s390xandlinux/riscv64transpiles. Every other target's generated code is byte-identical to v1.55.0 apart from the journal-rollback patch.Does the corruption bug reach lab's own store? Expected: no — but verify this reasoning rather than take it on faith. Two independent conditions have to hold for the bug to fire, and neither does here:
ATTACH) transaction.grep -rn 'ATTACH' internal/ migrations/finds zero hits (the only matches are the word "attach" in tmux-attach prose). Lab opens one database.journal_mode(WAL)in its DSN, and SQLite decides whether a commit needs a super-journal from a per-journal-mode table (aMJNeeded[]invdbeaux.c) in which WAL is marked as not needing one.So the fix is not urgent for us. It is still the right target, because the alternative — the
v1.55.0this issue previously specified — moves us onto the buggy 3.53.3 engine and buys nothing overv1.56.0.Does the DSN change break us? No — and here is the check. Our DSN recipe is pinned at
internal/store/store.go:84-86:We use the
_pragma=name(value)form and_txlock, not the mattn shorthand keys, so none of the newly-honored v1.55.0 keys appear in our DSN. The "validate every parameter first" change does cover the pre-existing_txlock, butimmediateremains a valid value. Re-readstore.gowhen you do this and confirm the DSN recipe has not drifted from the quote above.github.com/pressly/goose/v3v3.27.2 → v3.27.3 — UNBLOCKED as of 2026-08-04This issue previously said, in bold, "BLOCKED at v3.27.2, do not bump." That is no longer true, and the thing that changed is the publication of
sqlite v1.56.0. Re-derive it yourself; here is the arithmetic:goose v3.27.3requiresmodernc.org/sqlite v1.54.0andmodernc.org/libc v1.74.3 // indirect.modernc.org/libc v1.74.2andv1.74.3are retracted upstream ("freeaddrinfo leaks a locked___lockentry; deadlocks name resolution, fixed in v1.74.4" — the retraction directives are inlibc v1.74.4's owngo.mod).modernc.org/sqlite v1.56.0lockstep-pinsmodernc.org/libc v1.74.4exactly.Under MVS the selected versions are the maxima across the graph:
The retracted
v1.74.3is never selected — it is only required, and a higher version wins. So the lockstep holds and goose moves. This only works if you takesqlite v1.56.0. With the oldv1.55.0target (libcv1.74.1) the arithmetic giveslibc = v1.74.3, which is both retracted and a lockstep violation — that was the original block, and it is why the two bumps must land together.goose v3.27.3's release notes read, in full: "### Changed — Various dependency upgrades". No API change, no advisory. Lab's only goose surface isinternal/store/store.go(goose.DialectSQLite3/ the pgx dialect and the embeddedmigrations.SQLiteFS) — none of it touched.github.com/mattn/go-isattyv0.0.21 → v0.0.24 andgithub.com/sethvargo/go-retryv0.3.0 → v0.4.0 — now expected to moveThis issue previously said to leave both alone and treat any movement as a tripwire. That instruction is now inverted, because their floor came from
goose v3.27.2and both movers raise it:go-isatty→v0.0.24is required bysqlite v1.56.0(indirect).go-retry→v0.4.0is required bygoose v3.27.3(direct in goose).Both are indirect for us, neither has an advisory, and nothing in
internal/orcmd/imports either. Letgo mod tidyplace them. If either lands on a version other than the one above, that is worth a second look before proceeding.github.com/prometheus/client_golangv1.23.2 → v1.24.1go 1.26(go.mod:3) — fine.model.NameValidationScheme = LegacyValidationloses legacy enforcement. We never set it (no match forNameValidationSchemeanywhere underinternal/) — fine.api/prometheus/v1signature changes (Rules,LabelNames) andexp/api/remotereshaping. We import none of those packages — we useprometheus,promhttp, andcollectorsonly (internal/metrics/metrics.go,internal/metrics/lab.go) — fine.WithUnitoption,Desc.Err(). Additive.promhttp: fix panic on requests with a nil URL (#2065). We servepromhttp— a straight robustness win.internal/metrics/metrics_test.go:170asserts the presence oflab_http_requests_total,lab_http_request_duration_seconds, andgo_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/textv0.38.0 → v0.40.0 — the advisory fix (see Security §1). Indirect only; ridesclient_golang.github.com/golang-jwt/jwt/v5v5.2.1 → v5.3.1 — the advisory fix (see Security §2). Indirect only; ridesclient_golang. Betweenv5.2.1andv5.3.1upstream addedParseWithClaimsvalidator options and aClockSkewoption, and fixed theParseUnverifiedallocation bug that is CVE-2025-30204. We call none of it directly — webpush-go's signing path is the only consumer.go.yaml.in/yaml/v2v2.4.2 → v2.4.4 — patch releases on the drop-ingopkg.in/yaml.v2replacement. Single call site:internal/seeder/skillsindex.go:8. Ridesclient_golang.golang.org/x/cryptov0.52.0 → v0.54.0 — hygiene, and this is the issue's single answer on itEarlier comments on this issue disagreed about whether to move it. The answer is: move it. Nothing in the module graph requires more than
v0.52.0, sogo mod tidywill not raise it on its own — it needs an explicitgo get golang.org/x/crypto@v0.54.0.Between
v0.52.0andv0.54.0(golang/cryptocommit log, 2026-06-02 .. 2026-07-23) there are ~35 commits, all but two underssh/,ssh/agent,ssh/knownhosts,ssh/test,acme/,x509roots/fallback,ocsp/,pkcs12/oropenpgp/. We import exactly onex/cryptopackage,golang.org/x/crypto/argon2(internal/httpapi/password.go:11). The onlyargon2commit in the window is:A doc-comment change only — no exported signature, no default, no behavior.
internal/httpapi/password.go:23-29pins 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 touchdefaultArgonParams— it is a design §12 decision, not a copy of upstream's example. Expected code impact: zero.golang.org/x/syncv0.21.0 → v0.22.0 — hygiene, indirectPreviously needed an explicit
go get(it was pinned atv0.21.0bygoose v3.27.2).goose v3.27.3requiresv0.22.0, so MVS now carries it — no explicitgo getneeded. No advisory, no API this repo calls.Scope
go.mod,go.sum— the moving lines above, plus whatevergo mod tidypulls behind them.nix/package.nix:56—vendorHash. This is the trap. Both Go derivations share onegoModulesfetch (nix/package.nix:55), and the hash is hard-coded: Anygo.sumchange invalidates it and the hermetic nix gate (.forgejo/workflows/ci-nix.yml) fails with a fixed-output-derivation hash mismatch. Set it tolib.fakeHash, run the build, and paste thegot:hash from the error. This must land in the same commit as thego.modchange. Thego.sumdiff is larger than on previous passes (goose v3.27.3 drags a wide module graph), so this is more likely to bite, not less.How to verify
make testandmake lintare the Makefile equivalents of the middle two.If
go mod tidyreports a retractedmodernc.org/libcselection, stop — that meanssqlite v1.56.0did not land and the lockstep arithmetic above did not hold. Report it here rather than forcing it.Done means
go.modreads aftergo mod tidy, checked line by line.modernc.org/sqliteis atv1.56.0— notv1.55.0, which carries the SQLite 3.53.3 journal-rollback corruption bug.modernc.org/libcis exactly the versionmodernc.org/sqlite v1.56.0pins (v1.74.4), and is not the retractedv1.74.2/v1.74.3.github.com/pressly/goose/v3is atv3.27.3.github.com/golang-jwt/jwt/v5is atv5.3.1(or anything>= v5.2.2) — the advisory fix. It should arrive for free viaclient_golang; if it did not, raise it explicitly and find out why.github.com/mattn/go-isattyis atv0.0.24andgithub.com/sethvargo/go-retryis atv0.4.0— both carried by MVS, neither forced.nix/package.nixvendorHashregenerated in the same commit.go build ./...,go test ./...,golangci-lint runall green.govulncheck ./...reports no findings — in particular noGO-2026-5970and noGO-2025-3553.nix flake checkpasses (proves the vendorHash is right).internal/store/store.gois not edited as part of this.internal/httpapi/password.gois not edited — in particulardefaultArgonParamsis untouched.Closes #250.Out of scope
golang.org/x/sys,golang.org/x/term,pgx/v5,webpush-go,client_model,protobuf— already current, leave them alone.go 1.26) and the nixpkgs flake input.flake.lockis current — nixpkgs148bab9c, locked 2026-08-01, one day behindnixos-unstableHEAD (643809054d65, 2026-08-02) as of this sweep. Nothing to chase and no separate issue is owed.containers/agent-tools/versions.env) — those are their own issues: codex on #249, Claude Code on #235 and the 2.1.221 issue.actions/checkout@v7,actions/setup-node@v7,actions/setup-go@v7,actions/cache@v6across all four workflows; all current.Filed by the Daily agent update check schedule, 2026-07-31; body corrected 2026-08-02 (goose moved from "bump" to "blocked"), 2026-08-03 (second advisory
GO-2025-3553added, MVS analysis added, x/crypto and x/sync folded in from comments, indirect block swept) and 2026-08-04 (sqlite v1.56.0 published — retargets sqlite/libc, unblocks goose, inverts the two held indirects). Versions fromproxy.golang.org/<module>/@latest; advisory data fromvuln.go.dev; changelogs from each project's own release notes.Finding:
goose/v3cannot 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 requiresmodernc.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.0lockstep-pinslibc v1.74.1exactly.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 getconfirms: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 getopportunistically movedgolang.org/x/cryptov0.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.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/cryptois NOT currentThe body lists
golang.org/x/crypto v0.52.0under "Already current, do not touch". It is not:go.mod:12pinsv0.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/cryptocommit log, 2026-06-02 .. 2026-07-23): ~35 commits, of which all but two are underssh/,ssh/agent,ssh/knownhosts,ssh/test,acme/,x509roots/fallback,ocsp/,pkcs12/, oropenpgp/. This repo imports exactly onex/cryptopackage —golang.org/x/crypto/argon2(internal/httpapi/password.go:11). The onlyargon2commit in the window is:That is a doc-comment change only — no exported signature, no default, no behavior.
internal/httpapi/password.go:23-29pins 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 touchdefaultArgonParams— it is a design §12 decision, not a copy of upstream's example.So: bump
golang.org/x/crypto v0.52.0 → v0.54.0as routine hygiene, expect zero code impact, and leavepassword.goalone.Correction 2 —
golang.org/x/syncis stale and was omitted entirelygo.mod:38pinsgolang.org/x/sync v0.21.0 // indirect; latest is v0.22.0. Not mentioned anywhere in the body. Indirect, low-risk, letgo mod tidycarry 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 fullvuln.go.devmodule 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 allfixed: 0.52.0; the one unfixed entryGO-2026-5932isx/crypto/openpgp, which we do not import.x/sysGO-2026-5024isfixed: 0.44.0(we are on v0.47.0). The body's security section is accurate as written.modernc.org/sqlite v1.56.0is still NOT on the Go module proxy — the body flagged this as a thing to re-check:v1.55.0remains the target. The lockstep requirement is unchanged: it pinsmodernc.org/libc v1.74.1exactly.modernc.org/libc @latestis 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 thev1.74.1thatsqlite v1.55.0pins, exactly as the body says.golang.org/x/term v0.45.0andgolang.org/x/sys v0.47.0really are current — those two entries in the "do not touch" list are correct.goose/v3stays at v3.27.2, blocked by the libc lockstep for the reason given in the earlier comment. Unchanged.Updated target table
go.modgolang.org/x/text(indirect)modernc.org/sqlitemodernc.org/libc(indirect)github.com/prometheus/client_golanggo.yaml.in/yaml/v2golang.org/x/cryptogolang.org/x/sync(indirect)github.com/pressly/goose/v3Everything else in the body — the
vendorHashtrap atnix/package.nix:56, the DSN check atinternal/store/store.go:83-86, theclient_golanganalysis, the verification commands, and the done-list — stands as written.Re-verified 2026-08-02 (Daily agent update check). Targets unchanged; the body has been corrected to fold in the
gooseblock.What changed on the issue since it was filed:
goosefinding from the 2026-07-31 comment is now in the body itself, not just a comment underneath it. It had been sitting in the evidence table asv3.27.2 → v3.27.3, in the scope list as "six lines", and in the Done checklist as "all six pins moved" — all three contradicted the comment. An implementing agent reading top-down would have bumped goose and broken the sqlite lockstep. The table row now reads staysv3.27.2, the module section spells out the MVS reasoning, and the checklist has an explicit goose is still v3.27.2 box plus a tripwire (libcabovev1.74.1means something pulled goose up).golang.org/x/cryptowas listed under "already current, do not touch". It is not current —v0.54.0is out and we pinv0.52.0. The conclusion is unchanged (no bump needed: every 2026 advisory is inx/crypto/ssh*, we import onlyargon2), but the stated reason was wrong and is now stated correctly.Nothing moved upstream in the two days since filing:
modernc.org/sqlite v1.56.0is documented on upstream'smasterchangelog but still has not published to the module proxy — the list still tops out atv1.55.0.v1.55.0remains the target.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]to 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 blocked) [schedule: Daily agent update check]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 blocked) [schedule: Daily agent update check]to chore(deps): Go module updates — advisories GO-2026-5970 (x/text) + GO-2025-3553 (golang-jwt), sqlite 1.55.0 (+libc lockstep), client_golang 1.24.1, x/crypto 0.54.0 (goose blocked) [schedule: Daily agent update check]Re-verified 2026-08-03 (Daily agent update check). Every previously-stated target is unchanged — but the sweep found a second security advisory this issue was missing, and the body has been rewritten around it.
New finding —
GO-2025-3553also reaches usThe body claimed, in bold, "One advisory reaches a version we pin: GO-2026-5970." That was wrong.
go.mod:22pinsgithub.com/golang-jwt/jwt/v5 v5.2.1, which is inside:Why the earlier passes missed it. The 2026-08-01 comment says it "Checked the full vuln.go.dev module index for all 13 modules in our graph."
go.moddeclares 34 modules — 10 direct and 24 indirect. Thirteen is the direct block plus a few; the indirect block was never swept. This pass checked all 34 against the completevuln.go.devmodule index. Seven modules appear in the index at all; of those, exactly two have an advisory whose affected range contains the version we pin —x/text(already known) andgolang-jwt/jwt/v5(new).Expected reachability: none.
jwt/v5arrives viawebpush-go v1.4.0, whosego.modrequires exactlyv5.2.1. Its only jwt call site isvapid.go:80—jwt.NewWithClaims(jwt.SigningMethodES256, …), the VAPID signing path thatinternal/push/sender.go:196drives. The advisory's affected symbol isParser.ParseUnverified; nothing here parses a JWT.govulncheckshould report it unreachable. Bumping is still right — it costs nothing (below) and a range-based scanner will flagv5.2.1indefinitely.It costs nothing because MVS already carries it.
client_golang v1.24.1's owngo.mod— the bump this issue already specified — requiresgithub.com/golang-jwt/jwt/v5 v5.3.1 // indirect:So one bump closes both advisories and carries four other targets. The risk was never that the fix was hard — it was that the done-list never told an implementing agent to check jwt landed, so a partial bump could have shipped looking complete. The Done section now has an explicit box for it.
Also folded into the body (were contradictions or omissions)
golang.org/x/cryptohad two conflicting answers across the comments. The 2026-07-31 implementation comment says it was reverted tov0.52.0because the body said leave it alone; the 2026-08-01 comment says "bump it as routine hygiene." An agent reading top-down got whichever it read last. The body now gives one answer — bump tov0.54.0— with the argon2 analysis (only two of ~35 commits are outsidessh*/acme/openpgp; the singleargon2commit0b316e7ee409is a doc-comment change) and an explicit do not touchdefaultArgonParams. It also notes MVS will not raise it, so it needs an explicitgo get.golang.org/x/sync v0.21.0 → v0.22.0existed only in a comment. Now in the body table, marked hygiene, with the same "needs an explicitgo get" note.prometheus/common v0.66.1 → v0.70.1andprometheus/procfs v0.20.1 → v0.21.1were stale and unlisted anywhere. Both rideclient_golang; now in the table.mattn/go-isatty v0.0.21(latestv0.0.24) andsethvargo/go-retry v0.3.0(latestv0.4.0). Both are pinned at exactly our versions bygoose v3.27.2, nothing else asks for more, neither has an advisory, so MVS will not raise them and forcing it buys nothing. There are now Done boxes asserting they stayed put.// indirectlines are expected.client_golang v1.24.1+common v0.70.1bring graph entries we do not carry (json-iterator/go,klauspost/compress,modern-go/*,jpillora/backoff,mwitkow/go-conntrack,x/net,x/oauth2). Whichever onesgo mod tidykeeps will show up. Normal, not a finding — but it enlarges thego.sumdiff, which is thevendorHashtrap.flake.lockwas actually moved on 2026-08-02 (commitbbc7f99, nixpkgsd407951→148bab9c,go_1_261.26.4 → 1.26.5), so it is current and nothing is owed.Re-confirmed unchanged (nothing moved upstream)
modernc.org/sqlite v1.56.0still has not published to the module proxy — third sweep in a row it is documented on upstreammasterbut absent from the proxy.v1.55.0remains the target, still lockstep-pinninglibc v1.74.1.goosestays blocked atv3.27.2for the reason in the 2026-07-31 comment.v3.27.3still requires the retractedlibc v1.74.3.@latestand expanded to name every module that really is current, so a future sweep does not have to re-derive which is which.Web/npm: investigated 2026-08-03, nothing actionable — no issue filed
The old out-of-scope line promised "Web/npm dependencies — separate issue." This closes that out. There is no issue to file, and the evidence is here so the next sweep skips it.
Zero advisories. All 270 packages in
web/package-lock.jsonwere submitted to the npm bulk advisory endpoint (registry.npmjs.org/-/npm/v1/security/advisories/bulk) at their locked versions. Empty response — no advisory against any installed version.Twelve of fifteen declared dependencies are already at upstream
latest, because the caret ranges float andpackage-lock.jsonhas kept up:@solidjs/router 1.0.0,solid-js 1.9.14,@playwright/test 1.62.1,@typescript-eslint/{eslint-plugin,parser} 8.65.0,typescript-eslint 8.65.0,eslint-plugin-solid 0.14.5,jsdom 30.0.1,prettier 3.9.6,vite 8.2.0,vite-plugin-solid 2.11.14,vitest 4.1.10.The three that are behind are all majors, and both upgrades are blocked upstream:
typescript6.0.3 → 7.0.2 (TS 7 is the native port). Blocked:typescript-eslint@8.65.0declarespeerDependencies.typescript: ">=4.8.4 <6.1.0", which excludes 7.x, and no stable typescript-eslint supports TS 7 yet (latestis 8.65.0; only alpha/canary tags exist beyond).web/package.jsonrunstsc --noEmitinnpm run build, so this is not optional tooling. Also worth recording: TypeScript published no 6.1 — the 6.x line ends at6.0.3(2026-04-16) — so the^6.0.3range cannot drift into the excluded<6.1.0boundary on its own. Nothing to do, and nothing latent.eslint9.39.5 → 10.8.0 (and@eslint/js9.39.5 → 10.0.1). Blocked oneslint-plugin-solid@0.14.5, which declarespeerDependencies.eslint: "^6.0.0 || ^7.0.0 || ^8.0.0 || ^9.0.0"— no^10— and has not published since 2024-12-11. There is no maintained successor (npm search turns up only@ssen/eslint-plugin-solid@2.0.0-next.5, a third-party prerelease fork). The plugin is used atweb/eslint.config.js:3.Worth recording precisely, because the obvious next question has already been answered: the plugin's code is forward-compatible; only its declared peer range is not. ESLint 10 removed the deprecated rule-context methods (
fix!: Remove deprecated rule context methods, #20086), andeslint-plugin-soliddoes callcontext.getScope/context.getSourceCode/context.markVariableAsUsed— but all three go through asrc/compat.tsshim that tries the modern API first:So ESLint 10 would probably work if the peer range were forced with an npm
overridesentry. That is not worth doing: it buys a version number, permanently installs an override hack against an abandoned plugin, and ESLint 10's other breaking changes (feat!: update eslint:recommended configuration,feat!: enable JSX reference tracking— which directly touches Solid's JSX andno-unused-vars) would likely churn source files. ESLint 9.39.5 is still upstream'smaintenancedist-tag and carries no advisory.Node runtime is fine either way.
jsdom@30.0.1has the strictestenginesin the tree (^22.22.2 || ^24.15.0 || >=26.0.0); CI usesactions/setup-nodewithnode-version: "24"(.forgejo/workflows/ci.yml:49-53) and nixpkgs at148bab9chasnodejs = nodejs_24, so both build paths satisfy it.chore(deps): Go module updates — advisories GO-2026-5970 (x/text) + GO-2025-3553 (golang-jwt), sqlite 1.55.0 (+libc lockstep), client_golang 1.24.1, x/crypto 0.54.0 (goose blocked) [schedule: Daily agent update check]to chore(deps): Go module updates — sqlite 1.56.0 (SQLite journal-rollback corruption fix, +libc 1.74.4 lockstep), goose 3.27.3 UNBLOCKED, advisories GO-2026-5970 (x/text) + GO-2025-3553 (golang-jwt), client_golang 1.24.1 [schedule: Daily agent update c…Re-verified 2026-08-04 (Daily agent update check).
modernc.org/sqlite v1.56.0finally published — and it changes three of this issue's conclusions. The body has been rewritten around it.The previous three sweeps (2026-08-01, -02, -03) each checked and reported the same thing: "
modernc.org/sqlite v1.56.0is documented on upstreammasterbut still has not published to the module proxy." It published 2026-08-03T14:31:47Z — roughly twelve hours after the 2026-08-03 sweep ran:Change 1 — the sqlite target moves to v1.56.0, and the reason is data corruption
This is the substantive finding.
v1.56.0's changelog entry, quoted in the body, describes a silent database-corruption bug in SQLite 3.53.3's journal rollback thatv1.54.0introduced andv1.55.0still carries:Upstream is explicit that this is not a transpilation artifact: "a plain gcc build of the stock 3.53.3 amalgamation fails on the same bytes while 3.53.2 recovers them," and it is what makes upstream's own
test/crash.testfail in ~2% of runs on every platform.Our current
v1.53.0embeds SQLite 3.53.2 — the version that recovers correctly. So thev1.55.0this issue specified for four days would have moved us off a correct engine onto a knowingly-corrupting one. Nobody implemented it, so nothing shipped, but the target was wrong and is nowv1.56.0.Reachability for lab's own store: expected none — stated in the body with the reasoning so it can be checked rather than believed. Two conditions must both hold and neither does: the bug needs a super-journal, which only exists for an
ATTACHtransaction (grep -rn 'ATTACH' internal/ migrations/→ zero hits), and it needs a hot rollback journal to replay, whileinternal/store/store.go:84-86pinsjournal_mode(WAL). The fix is therefore not urgent — butv1.56.0costs nothing overv1.55.0and is strictly better.Change 2 —
goose/v3is UNBLOCKEDThe body said, in bold, "BLOCKED at v3.27.2, do not bump", with a Done box and a tripwire built around it. That is no longer true, and the only thing that changed is which sqlite version we take.
The retracted
v1.74.3is only ever required, never selected, once a higher version is in the graph — andv1.74.4is the release that fixes the veryfreeaddrinfodeadlock the retraction cites (its retraction directives are inlibc v1.74.4's owngo.mod, which I read to confirmv1.74.4is not itself retracted).So
goose v3.27.3lands, the lockstep holds, and the "iflibcgoes above the pin, something pulled goose up" tripwire has been rewritten (it now trips on a retracted selection instead). This only works if the sqlite bump goes to v1.56.0 — the two must land together, which the body now says explicitly.Change 3 — the two "do not move" indirects are now expected to move
The body told an implementing agent that
github.com/mattn/go-isattyandgithub.com/sethvargo/go-retrymust stay put, with Done boxes asserting it and an instruction to stop and investigate ifgo mod tidymoved either. That was correct only while goose was held at v3.27.2, which is what pinned their floor. With the movers above:mattn/go-isattyv0.0.21→v0.0.24— required bysqlite v1.56.0(indirect).sethvargo/go-retryv0.3.0→v0.4.0— required bygoose v3.27.3(direct in goose).Both instructions are inverted in the body, and the Done boxes now assert the new versions. Left as-is, they would have sent an agent chasing a phantom regression on a correct
go mod tidyresult.Knock-on:
golang.org/x/sync v0.22.0no longer needs an explicitgo geteither —goose v3.27.3requires it, so MVS carries it.golang.org/x/cryptois now the only target needing an explicitgo get.Also expect two new indirects from sqlite v1.56.0 that no previous sweep anticipated:
github.com/google/pprofandmodernc.org/fileutil v1.4.0. Combined with the goose graph this makes thego.sumdiff considerably larger than previously estimated — which raises, not lowers, the odds of thenix/package.nix:56vendorHashtrap biting. That warning is unchanged and still the most likely way this PR fails CI.Unchanged — re-confirmed against
proxy.golang.org/@latest, 2026-08-04Both advisories (
GO-2026-5970x/text,GO-2025-3553golang-jwt) still reach the versions we pin; the full 34-modulevuln.go.devsweep from 2026-08-03 was re-run and turned up nothing new. Everything on the "already current, do not touch" list is still at@latest. Theclient_golang,x/crypto/argon2 and DSN analyses stand as written.Adjacent surfaces re-checked this sweep — nothing to file
flake.lock— nixpkgs148bab9c, locked 2026-08-01;nixos-unstableHEAD is643809054d65(2026-08-02). One day behind. Nothing owed.typescript-eslint(and@typescript-eslint/*)8.65.0→8.66.0, andeslint10.7.x→10.8.0. Neither changes anything.typescript-eslint@8.66.0still declarespeerDependencies.typescript: ">=4.8.4 <6.1.0", so TypeScript 7.0.2 stays blocked and there is still no stable typescript-eslint v9.eslint-plugin-solidis still0.14.5(last published 2024-12-11) withpeerDependencies.eslint: "^6 || ^7 || ^8 || ^9", so ESLint 10.8.0 stays blocked. The lockfile is otherwise atlateston every floating range (vite 8.2.0, vitest 4.1.10, prettier 3.9.6, @playwright/test 1.62.1, vite-plugin-solid 2.11.14, solid-js 1.9.14, jsdom 30.0.1). A lonetypescript-eslint8.65→8.66 bump is not worth an agent run.actions/checkout@v7,actions/setup-node@v7,actions/setup-go@v7,actions/cache/{restore,save}@v6acrossci.yml,ci-nix.yml,deploy.yml,agent-tools.yml. All current.containers/agent-tools/Containerfile.claudeusesgolang:1.26-alpine(floating; currently resolves to 1.26.5) andalpine:3.22(floating within 3.22.x; upstream latest line is 3.24). Both are build stages only — the shipped image isFROM scratch— andalpine:3.22still receives security patches, which the floating tag picks up automatically. Not worth an issue.0.146.0still the newest stable), Claude Code on #235 plus a new issue for2.1.221, which published 2026-08-03 and carries a Bash-tool permission-check fix.chore(deps): Go module updates — sqlite 1.56.0 (SQLite journal-rollback corruption fix, +libc 1.74.4 lockstep), goose 3.27.3 UNBLOCKED, advisories GO-2026-5970 (x/text) + GO-2025-3553 (golang-jwt), client_golang 1.24.1 [schedule: Daily agent update c…to chore(deps): Go modules — sqlite 1.56.0 (corruption fix) + libc 1.74.4 lockstep, goose 3.27.3 unblocked, advisories GO-2026-5970 + GO-2025-3553 [schedule: Daily agent update check]Re-verified 2026-08-05 (Daily agent update check). Every target version in the rewritten body is still upstream
@latest— no edits needed. The body stands exactly as rewritten on 2026-08-04.Full
proxy.golang.org/<module>/@latestsweep of all 29 modules ingo.mod, today:That is exactly the body's table — same 13 modules, same targets, nothing added, nothing moved. In particular
modernc.org/sqliteis stillv1.56.0(nov1.57.xsince the 2026-08-03 publish that triggered the rewrite) andmodernc.org/libcis stillv1.74.4, so the lockstep pair is unchanged andgoose v3.27.3stays unblocked.The remaining 16 modules re-confirmed at
@latest, matching the body's "already current, do not touch" list:pgx/v5 v5.10.0,webpush-go v1.4.0,client_model v0.6.2,x/sys v0.47.0,x/term v0.45.0,protobuf v1.36.11,mathutil v1.7.1,memory v1.11.0,uuid v1.6.0,xxhash/v2 v2.3.0,go-humanize v1.0.1,go-strftime v1.0.0,puddle/v2 v2.2.2,interpolate v0.0.2,multierr v1.11.0,perks v1.0.1.Advisory re-check — no new advisory reaches any pin, and the body's
x/cryptoreasoning is confirmedQueried
api.osv.dev/v1/querybatchfor all 18 non-trivial modules at their currently pinned versions. Exactly three hits, all already in the body:GO-2026-5932is the one the body dismisses, and the dismissal is correct — confirmed against the advisory's own affected-imports list this run:Every affected import is under
openpgp/. This repo imports exactly onex/cryptopackage,golang.org/x/crypto/argon2(internal/httpapi/password.go:11), so the advisory does not reach us and — note for the implementer — it will still be "open" againstv0.54.0after the bump, because it has no fixed version. That is expected and is not a reason to hold the bump:govulncheckreports on the call graph, so it will stay clean. Thex/cryptorow remains hygiene, exactly as the body says.So the security section is unchanged:
GO-2026-5970(x/text, fixed 0.39.0) andGO-2025-3553(jwt/v5, fixed 5.3.0) remain the only two advisories that reach a pin we carry, and both are closed by the targets already in the table.Nothing to correct. This comment exists so the next sweep can see the full graph was re-swept rather than assumed.
Companion sweeps this run, for cross-reference: codex on #249 (re-verified, no change), and a new issue #290 — Claude Code
2.1.221→2.1.222. Also swept and found clean, so nobody re-derives them: theweb/npm dependency tree (everything at@latestexcepttypescript-eslint8.65.0 → 8.66.0; ESLint 10 and TypeScript 7 are both blocked by upstream peer ranges, see #290's sibling note), thebuildpack-deps:stable-scmdigest innix/module.nix(byte-identical to the tag's current digest), and the Forgejo workflow action pins (checkout@v7,setup-node@v7,setup-go@v7,cache@v6— all current majors).