build(deps): Bump golang.org/x/crypto from 0.53.0 to 0.54.0

[dependabot]

Bumps golang.org/x/crypto from 0.53.0 to 0.54.0.

Commits

• cdce021 go.mod: update golang.org/x dependencies
• d9474cc openpgp: make the deprecation message more explicit
• 7626c50 ssh: verify declared key type matches decoded key in authorized_keys
• 0471e79 ssh/agent: enforce strict limits on DSA key parameters
• 6435c37 ssh: sanitize client disconnect messages
• 7d695da ssh/agent: drain channel stderr in agent forwarders
• 5b7f841 acme/autocert: fix data race in Manager.createCert
• 0b316e7 argon2: update RFC 9106 parameter recommendations
• 55aec0a x509roots/fallback: update bundle
• 5f2de1a internal: remove wycheproof tests
• See full diff in compare view

[lklimek]

Dependency Security Review — golang.org/x/crypto 0.53.0 → 0.54.0

Verdict: SAFE — recommend merge.

Scope

Only go.mod/go.sum change. Dependabot bundled the related x/ modules: x/sync 0.21→0.22, x/sys 0.46→0.47, x/term 0.44→0.45, x/text 0.38→0.40, x/tools 0.46→0.47.

10 upstream commits; real code touches only ssh/, acme/autocert/, argon2/ (docs), openpgp/ (deprecation text), plus a CA-bundle refresh and removal of the wycheproof test suite.

Supply chain

• All six new h1:/go.mod hashes match the sum.golang.org transparency log.
• go mod verify → "all modules verified"; go mod tidy is a no-op.
• All commits authored by upstream maintainers with Gerrit review trails. Normal monthly cadence, no anomalies.

Known vulnerabilities

Advisory	Package	Affects 0.53.0 chain?	Fixed here?
GO-2026-5970 / CVE-2026-56852 — infinite loop in unicode/norm on invalid UTF-8	x/text <0.39.0	Yes (0.38.0)	Yes, via bundled x/text 0.38→0.40
GO-2026-5932 — openpgp unmaintained by design	x/crypto (all)	Informational; not in graph	N/A
—	x/sync, x/sys, x/term, x/tools	None	—

The x/text fix is the only registered security gain. Reachability: cmd → viper → afero → unicode/norm, but afero only calls norm from NeuterAccents, which nothing here invokes — pre-existing exposure was linkage-only, not exploitable. The bump removes it from the graph anyway.

Upstream fixes in 0.54.0 (severity = of the pre-fix bug)

Sev	Finding	Location
HIGH	authorized_keys option bypass — restrict <key> with the key type omitted parsed as an unrestricted key (option token silently discarded). Declared type must now match the blob.	ssh/keys.go
MEDIUM	ssh/agent parseDSAKey built a dsa.PrivateKey with zero validation → CPU-exhaustion DoS from oversized P/Q/G/Y. Now bounds-checked.	ssh/agent/server.go
MEDIUM	Terminal escape/control-char injection: peer SSH_MSG_DISCONNECT formatted raw into an error string. Now stripped and %q-escaped.	ssh/messages.go
MEDIUM	Agent-forwarding memory pin: channel stderr never drained (up to 2 MiB/channel + silent stall).	ssh/agent/forward.go
LOW	Data race on certState.locked read outside any lock.	acme/autocert/autocert.go
INFO	argon2 RFC 9106 parameter guidance — doc comment only, zero behavior change.	argon2/argon2.go

Notable: none of these five received a CVE, GHSA, or GO-ID. vuln.go.dev's x/crypto index ends at GO-2026-5932 and GitHub's advisory DB has zero x/crypto advisories after 2026-07-01. So neither govulncheck nor Dependabot would ever have flagged 0.53.0 for any of them — routine x/crypto minor bumps should be treated as security-relevant by default rather than waiting for an alert.

Impact on tenderdash

go mod why confirms the ssh, ssh/agent, acme/autocert, and openpgp packages are not in this module's graph — every fix above is N/A here.

Tenderdash's actual x/crypto surface is chacha20poly1305, curve25519, hkdf, nacl/box (internal/p2p/conn/secret_connection.go, privval/secret_connection.go) and ripemd160 (crypto/secp256k1/secp256k1.go). A path-scoped diff between the two tags shows zero code changes in those packages plus internal/poly1305 and internal/alias — the p2p/privval STS handshake is byte-for-byte unaffected.

One behavior change to note for the future: x/sync/semaphore now panics on negative weight. Tenderdash imports only errgroup, never semaphore.

CI note — the govulncheck failure is not caused by this PR

Everything else passes (build, lint, all 6 test shards, both e2e suites, check-proto, check-mocks). The scan failed on GO-2026-5856, a Go stdlib crypto/tls ECH privacy leak — Found in: crypto/tls@go1.26.4, Fixed in: crypto/tls@go1.26.5. No dependency bump can fix that; it needed the toolchain bump, which has since landed on v1.6-dev (#1395). Requesting a rebase so this PR picks it up.

Follow-ups (out of scope for this PR)

1. build(deps): Bump golang.org/x/sys from 0.46.0 to 0.47.0 #1384, build(deps): Bump golang.org/x/sync from 0.21.0 to 0.22.0 #1387, build(deps): Bump golang.org/x/term from 0.44.0 to 0.45.0 #1389 are superseded — this PR already bumps x/sys 0.47, x/sync 0.22, x/term 0.45 to the same versions.
2. Makefile:279 pins govulncheck@v1.3.0; current is v1.6.0. A stale scanner ships stale detection logic.
3. privval/dash_core_mock_signer_server.go:28 hardcodes jrpc.Auth("user", "password") in a file with no _test.go suffix and no build tag. NewDashCoreMockSignerServer is never constructed anywhere in the repo — dead code that nonetheless drags go-pkgz/jrpc (and transitively argon2) into the production dependency graph. Worth a build tag or deletion.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[lklimek]

@dependabot rebase

[lklimek]

@dependabot rebase

[lklimek]

CI diagnosis — tests (01) / tests (02) are pre-existing flakes, not an x/crypto regression

The post-rebase run (30377816944, head 5615c13) is green everywhere that matters — govulncheck now passes, confirming the toolchain bump (#1395) landed and resolved GO-2026-5856 as predicted in the audit above. Build, lint, check-proto, check-mocks, both e2e suites, and test shards 00/03/04/05 all pass.

The two remaining failures:

Shard	Test	Package
tests (01)	TestReactorValidatorSetChanges (120.07s — hit its deadline)	internal/consensus
tests (02)	TestRouter_Channel_Broadcast (2.01s)	internal/p2p

Why neither is caused by this PR

TestReactorValidatorSetChanges fails identically on v1.6-dev itself, on commits that have nothing to do with this bump:

• run 30377407879 — --- FAIL: TestReactorValidatorSetChanges (120.08s)
• run 30373884936 — --- FAIL: TestReactorValidatorSetChanges (120.08s)

Same test, same shard, same ~120s timeout signature, base branch, no dependency changes involved. That is a pre-existing flake in the consensus reactor's validator-set-rotation path, not a regression. The logged errors (peer sent a vote with an invalid vote index, reactor is closed) are the usual shutdown-race noise as the test tears down past its deadline.

TestRouter_Channel_Broadcast fails at p2ptest/require.go:51-52 — the assert.True(t, count >= 1) guard inside RequireReceive, which wraps the receive in a 1-second context.WithTimeout. A one-second budget for a broadcast fan-out on a contended CI runner is a timing assertion, not a correctness one; it fails when the runner is loaded — and shard 02 was running concurrently with five other shards plus two e2e suites, against a visibly congested runner queue.

Why the bump can't be the cause mechanically

Per the audit above, a path-scoped diff between x/crypto v0.53.0 and v0.54.0 shows zero code changes in every package tenderdash actually links: chacha20poly1305, curve25519, hkdf, nacl/box, ripemd160, internal/poly1305, internal/alias. The p2p handshake in internal/p2p/conn/secret_connection.go is byte-for-byte unaffected. There is no code path by which this diff could change consensus reactor timing or p2p broadcast delivery.

Neither failing test touches crypto primitives at all — one is consensus validator rotation, the other is router message fan-out.

Action

Re-running the two failed shards rather than requesting another rebase: the rebase already happened (head 5615c13) and already delivered the only thing it needed to — the toolchain fix that turned govulncheck green.

Verdict: not a regression. The bump remains SAFE to merge once the flakes clear on re-run.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}