build(deps): Bump github.com/bufbuild/buf from 1.71.0 to 1.72.0

[dependabot]

Bumps github.com/bufbuild/buf from 1.71.0 to 1.72.0.

Release notes

Sourced from github.com/bufbuild/buf's releases.

v1.72.0

• Fix buf beta registry webhook create and buf beta registry webhook list to emit proto JSON output.
• Fix HTTPS Basic authentication for remote inputs to use BUF_INPUT_HTTPS_USERNAME for the username.
• Fix IMPORT_USED lint rule silently reporting no unused imports when google/protobuf/descriptor.proto is in the transitive dependency graph.

Changelog

Sourced from github.com/bufbuild/buf's changelog.

[v1.72.0] - 2026-07-17

• Fix buf beta registry webhook create and buf beta registry webhook list to emit proto JSON output.
• Fix HTTPS Basic authentication for remote inputs to use BUF_INPUT_HTTPS_USERNAME for the username.
• Fix IMPORT_USED lint rule silently reporting no unused imports when google/protobuf/descriptor.proto is in the transitive dependency graph.

Commits

• 7d6f056 Release v1.72.0 (#4617)
• 46fa3e4 Make upgrade (#4616)
• efe167b Fix buf generate clean to not delete nested output (#4615)
• f6c012f Make upgrade (#4608)
• 67dfe4c Fix IMPORT_UNUSED when descriptor.proto is in the dependency graph (#4602)
• b518200 Fix HTTPS Basic auth for env variables (#4600)
• e2b3f44 Add recommended SDK added/removed audit events (#4601)
• 58b4fc0 Make upgrade (#4599)
• f0f8156 Fix webhook create/list output to use protojson (#4592)
• ce80ea7 Return to development (#4584)
• See full diff in compare view

[lklimek]

⚠️ Merge conflict

This PR is currently CONFLICTING against v1.6-dev. The base branch has since absorbed two other dependency bumps that also touch go.mod/go.sum:

• build(deps): Bump github.com/adlio/schema from 1.5.0 to 1.5.1 (build(deps): Bump github.com/adlio/schema from 1.5.0 to 1.5.1 #1381)
• build(deps): Bump golang.org/x/sync from 0.21.0 to 0.22.0 (build(deps): Bump golang.org/x/sync from 0.21.0 to 0.22.0 #1387)

The conflict is purely lockfile churn — no semantic overlap with the buf bump. Requesting a rebase so CI runs against an up-to-date base.

@dependabot rebase

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

[lklimek]

🔍 Dependency review — github.com/bufbuild/buf 1.71.0 → 1.72.0

Verdict: ✅ No security concerns. Safe to merge once CI is green.

Scope

Diff touches go.mod/go.sum only (44 / 84 lines). No source changes.

Upstream changes (v1.72.0, 2026-07-17)

A pure bugfix release — three entries, no features, no deprecations, no breaking changes:

1. buf beta registry webhook create|list now emit proto JSON output.
2. HTTPS Basic auth for remote inputs uses BUF_INPUT_HTTPS_USERNAME for the username.
3. IMPORT_USED lint rule no longer silently reports zero unused imports when google/protobuf/descriptor.proto is in the transitive dependency graph.

Codegen / build impact

buf is a build-time-only dependency here — blank-imported in tools/tools.go and invoked via go run github.com/bufbuild/buf/cmd/buf in the Makefile (generate, lint, breaking). It is not linked into any shipped tenderdash binary, so its supply-chain surface is confined to CI and developer machines.

Only item 3 is behaviourally relevant to this repo: the IMPORT_USED fix makes buf lint stricter, so it could newly surface unused imports in our .proto files. check-proto and check-mocks both passed, confirming no new lint violations and byte-identical generated output. Items 1 and 2 touch BSR webhook/remote-input paths this repo does not use.

Transitive fallout worth naming

Because tools/tools.go shares the main module graph, MVS pulls several direct runtime dependencies forward alongside buf:

Module	Before	After
golang.org/x/crypto	0.53.0	0.54.0
golang.org/x/net	0.56.0	0.57.0
golang.org/x/sys	0.46.0	0.47.0
golang.org/x/term	0.44.0	0.45.0
golang.org/x/text	0.38.0	0.40.0
golang.org/x/tools	0.46.0	0.48.0

These are routine upstream point releases, but note that a bump labelled as tooling-only does reach the shipped binary via x/crypto and x/net. govulncheck passed, reporting no known advisories against the resulting graph.

Remaining movement is build-tooling only: protocompile, cel-go 0.28.1→0.29.2, docker/cli, moby/*, go-containerregistry, klauspost/compress, and the buf.build/gen/go/* generated modules.

Supply chain

• Bump authored by Dependabot against the upstream bufbuild/buf release tag; no maintainer or ownership change.
• go.sum hashes updated consistently; no replace directives, no forks, no version downgrades.
• No new top-level dependencies introduced.

Notes

Originally conflicted against v1.6-dev after #1381 and #1387 landed; rebased to 5a9335c2, now MERGEABLE with the x/sync overlap resolved by the base branch.

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

[lklimek]

📌 Addendum — this bump also remediates a live advisory

Follow-up to my review above, which understated the transitive x/text movement as "routine". It isn't. Independently verified against the OSV API:

GO-2026-5970 / CVE-2026-56852 — "Infinite loop on invalid input in golang.org/x/text" (published 2026-07-14, REVIEWED)

• Affected range: introduced: 0 → fixed: 0.39.0
• Affected symbols: norm.Iter.Next, norm.Iter.Seek, Form.Span, Form.Transform, and the rest of golang.org/x/text/unicode/norm
• A norm.Iter can enter an infinite loop on input containing invalid UTF-8 bytes

v1.6-dev currently sits on golang.org/x/text v0.38.0 — inside the affected range. This PR moves it to v0.40.0, which OSV returns clean. So the bump is not merely neutral, it closes a DoS-shaped advisory on the base branch.

Reachability is the mitigating factor: CI govulncheck is green on both sides, meaning the vulnerable unicode/norm symbols are not reachable from tenderdash's own call graph. That keeps this LOW severity in practice and not a merge blocker on its own — but it does turn "routine point release" into a positive reason to land this sooner rather than later.

Non-blocking, outlives this PR

.github/workflows/proto-lint.yml lints protos with a hand-typed buf version:

- uses: bufbuild/buf-setup-action@v1.50.0
  with:
    version: "1.59.0"     # line 19

No Dependabot ecosystem parses that string, so CI proto-linting stays pinned at buf 1.59.0 while go.mod advances to 1.72.0 — a 13-minor-version drift that will keep widening silently with every bump like this one. The same file also uses bufbuild/buf-lint-action@v1 (mutable major tag) and declares no permissions: block, so it inherits the repo-default token scope.

Both are pre-existing CI-hygiene items, unrelated to this diff. Worth a separate issue rather than scope-creeping a Dependabot PR.

Verdict unchanged: ✅ safe to merge on green CI, now with a mild argument for prioritising it.

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

[lklimek]

🔧 Correction to my own review

A deeper audit pass turned up two places where my earlier comments were wrong or overstated. Correcting the record — I re-verified each claim myself rather than relaying it.

1. "govulncheck passed, no known advisories against the resulting graph" — overstated

govulncheck never sees buf at all. Makefile:279 runs govulncheck ./..., and tools/tools.go carries //go:build tools, so the buf import is excluded from the default build:

$ go list -deps ./...                    | grep -c bufbuild   →  0
$ go list -deps -tags tools ./tools/...  | grep -c bufbuild   →  1

Zero bufbuild packages in the scanned graph. The gating govulncheck job is structurally blind to the entire Buf CLI tree — a critical advisory in buf would pass it silently. My green-govulncheck reassurance covered the runtime graph only, and should not have been extended to buf itself. Same blind spot applies to golangci-lint and mockery.

Fix (separate PR): govulncheck -tags tools ./....

2. "Vulnerable x/text symbols are not reachable" — right conclusion, sloppy wording

To be precise, two different things were conflated:

• Package presence: golang.org/x/text/unicode/norm is in the shipped binary's graph — it pulls in via viper→afero. go list -deps ./cmd/... returns it (763 deps total). My implication that it was absent was wrong.
• Symbol reachability: govulncheck is symbol-level, and it is green on v1.6-dev itself (runs 5e96eadd, a06df107, cd27f3cd all success) while that branch sits on the vulnerable x/text v0.38.0. So the vulnerable norm.Iter symbols genuinely are not called from our code.

Net: GO-2026-5970 is present-but-not-called on the base branch. Severity assessment is unchanged (LOW in practice), and the bump still closes it.

(Methodology note, since it nearly produced a wrong published claim: my first go list run returned 0 for everything because it was failing on error obtaining VCS status inside the git worktree, with stderr suppressed. -buildvcs=false gives the real numbers. A silent zero and a true zero look identical — worth remembering.)

3. Framing correction

I led with "buf is build-time-only, so its supply-chain surface is confined to CI." That bounds buf's own code, but not this PR: tools/tools.go lives in the main module, so MVS propagates buf's requirements into tenderdash's runtime graph — which is exactly how x/crypto, x/net and x/text moved here. This diff is correctly reviewed as a runtime change, not a tooling change. Worth considering splitting tools.go into its own nested module so tool bumps stop moving the consensus node's crypto floor.

Unchanged

Diff integrity is clean: go.sum hashes match the public Go checksum transparency log, go mod verify passes, go mod tidy reproduces both files byte-identically, no new build hooks or outbound calls. The upstream v1.71.0 credential-in-Basic-auth-username bug that v1.72.0 fixes is not reachable here — no BUF_INPUT_HTTPS_* vars set, no remote HTTPS inputs in buf.yaml.

Verdict still ✅ merge on green. All follow-ups above belong in separate PRs, not this one.

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

[lklimek]

Follow-ups from this audit filed separately, so they don't scope-creep the bump:

• govulncheck is blind to build-tool dependencies (buf, golangci-lint, mockery) #1402 — govulncheck is blind to build-tool dependencies (buf, golangci-lint, mockery)
• proto-lint.yml pins buf via a hand-typed version string Dependabot cannot update #1403 — proto-lint.yml pins buf via a hand-typed version string Dependabot cannot update
• Split tools.go into a nested module so tool bumps stop moving runtime dependency floors #1404 — split tools.go into a nested module so tool bumps stop moving runtime dependency floors

None block this PR.

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

[lklimek]

⚠️ Conflicting again — second rebase

v1.6-dev moved again while this PR's CI was still running. Three more commits landed, one of which collides on go.sum:

• 5a2ac4b83 — Bump golang.org/x/crypto from 0.53.0 to 0.54.0 (build(deps): Bump golang.org/x/crypto from 0.53.0 to 0.54.0 #1383)
• c462a7742 — Bump actions/stale from 10 to 11 (build(deps): Bump actions/stale from 10 to 11 #1401)
• f8eeb6d22 — Bump docker/login-action from 4.4.0 to 4.5.2 (build(deps): Bump docker/login-action from 4.4.0 to 4.5.2 #1400)

#1383 lands the same x/crypto 0.53.0 → 0.54.0 that this PR carries transitively, so this is again pure lockfile overlap with no semantic disagreement.

@dependabot rebase

Amendment to my addendum

Base is now on golang.org/x/text v0.40.0, so GO-2026-5970 is already remediated on v1.6-dev — it came along transitively with #1383. My earlier framing ("this PR closes a live advisory on the base branch") was true when written but has been overtaken. This PR is now neutral on that advisory rather than remediating it. Everything else in the review stands.

Process note

This is the second rebase caused purely by an adjacent Dependabot PR touching go.sum. Full CI here runs ~20 minutes while the bump queue is landing faster than that, so lockfile PRs can end up on a treadmill where each rebase is invalidated before its checks finish. A merge queue, or merging go.mod-touching bumps in one batch, would avoid burning CI cycles on repeated rebases. Not actionable in this PR.

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

[lklimek]

🛑 Merge on hold — do not land yet

Please do not merge this PR, even once CI is fully green.

#1385 carries the fix for CVE-2026-39821 (CVSS 9.6) in golang.org/x/net and is currently stuck on a rebase treadmill. Every go.mod-touching merge — this PR included — re-conflicts it and restarts its ~35 minute CI run. Landing this bump first would push the critical fix further out.

Order of operations: #1385 lands first, then this.

The review verdict here is unchanged (✅ low risk, approve), and I'll keep this branch rebased and ready so it can go in promptly once #1385 is clear. This is a sequencing hold, not a concern with the change.

Concrete instance of the CI-race pattern noted in my previous comment — with the priority inverted the wrong way round.

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

[lklimek]

✅ Hold lifted — tests (01) failure is a pre-existing flake, not a regression

#1385 landed as 0377e1d9, so the sequencing hold is cleared. This PR is MERGEABLE against the new base without needing another rebase — base now independently carries x/crypto v0.54.0, x/net v0.57.0 and x/text v0.40.0, so the earlier lockfile overlap resolved itself.

The tests (01) failure

TestReactorValidatorSetChanges (internal/consensus) failed on head 5e0070e2:

reactor_test.go:192: waitForAndValidateBlock deadline for node 6: context deadline exceeded
reactor_test.go:628: encountered timeout: context deadline exceeded
FAIL github.com/dashpay/tenderdash/internal/consensus  167.820s

This is not caused by this PR. Evidence rather than assertion — the identical test fails intermittently on v1.6-dev itself:

Run	Branch	Commit	Failing test
30377407879	v1.6-dev	2e125053	TestReactorValidatorSetChanges — same test, same package
30381042778	v1.6-dev	c4063ef0	TestRouter_EvictPeers (internal/p2p)

Both are timeout-shaped failures in timing-sensitive consensus/p2p tests on the base branch, with no #1397 involvement.

Causally this PR also cannot reach that code: the diff is go.mod/go.sum only, and buf is behind //go:build tools — go list -deps ./... resolves zero bufbuild packages into the tested graph. The other five test shards, govulncheck, golangci-lint, check-proto, check-mocks, test_apps and test_abci_cli all passed on this same commit.

Re-ran the failed job rather than requesting another rebase — a rebase would restart all 16 checks and re-enter the treadmill for no benefit, given the PR is already cleanly mergeable.

Two flaky tests worth their own issue: TestReactorValidatorSetChanges and TestRouter_EvictPeers. Not filing that from here to avoid further scope creep on a dependency bump.

Merging once the re-run is green.

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

[lklimek]

⚠️ Third conflict — go.sum treadmill

46ba46b02 — Bump github.com/prometheus/client_golang (#1398) — landed on v1.6-dev while this PR's re-run was one check from green. Conflicts on go.sum again. No semantic disagreement, same lockfile-churn pattern as the previous two.

@dependabot rebase

This PR has now been invalidated three times without ever reaching a merge

#	Trigger	Outcome
1	#1381, #1387 landed	rebased → full CI restart
2	#1383, #1400, #1401 landed	rebased → full CI restart
3	#1398 landed	rebased → full CI restart

Full CI here is ~20 minutes; go.mod-touching bumps have been landing roughly every 10–15. A lockfile PR cannot win that race — each rebase is invalidated before its checks finish. Across three runs this PR has consumed roughly 48 CI jobs and produced zero actual defects: every check has passed except one TestReactorValidatorSetChanges timeout, which also fails on v1.6-dev unaffected by this PR.

This is a scheduling problem, not a quality problem. Two things would fix it:

1. A merge queue on v1.6-dev — the standard remedy; it serialises go.sum bumps and rebases them automatically without burning a full CI cycle per collision.
2. Batching go.mod bumps — Dependabot groups: config lands them as one PR with one CI run instead of N mutually-invalidating PRs.

Until then, landing these reliably requires briefly pausing other go.mod merges so one PR can get through its ~20 minute window.

Review verdict is unchanged and has been stable since the first pass: ✅ low risk, approve.

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