[v0.20.x-branch] Backport #11105: build: bump grpc to v1.83.1 - #11110
Conversation
ziggie1984
added
no-changelog
severity-critical
Point the google.golang.org/protobuf replace at the lightninglabs/protobuf-go-hex-display v1.36.11-hex-display tag, matching what master carries since 3f3718c (lightningnetwork#10887). This moves only the runtime backing the replace; the required protobuf version is untouched, so the protoc-gen-go version derived from go.mod is unchanged and the generated stubs stay as they are. The UseHexForBytes option used by the lncli JSON marshal and unmarshal paths is preserved.
Raise the required google.golang.org/protobuf version to v1.36.11, the version the hex display fork now tracks. grpc v1.83.1 requires this version too, so doing it here keeps the grpc bump that follows free of generated-code churn. lnrpc/gen_protos_docker.sh derives PROTOBUF_VERSION from the protobuf version selected in go.mod, so protoc-gen-go moves from v1.33.0 to v1.36.11 and the stubs have to be regenerated for 'make rpc-check' to stay clean. The diff is large but mechanical: the v1.36 generator emits each file descriptor as a string constant instead of a []byte literal, which accounts for nearly all of it. No RPC definitions change, and the output matches what master already carries.
(cherry picked from commit ad7ccc0)
x/crypto v0.51.0 adds a second failure mode to chacha20poly1305.New: it now returns an error under Go's strict FIPS 140-only mode, in addition to the existing bad-key-length case. The key here is a fixed [32]byte, and lnd cannot run under strict FIPS mode because brontide mandates ChaCha20-Poly1305, so the discarded error remains unreachable. Expand the comment to record that widened invariant. (cherry picked from commit 8a23e33)
12be235 to
b32c7d1
Compare
🔴 PR Severity: CRITICAL
🔴 Critical (1 file)
🟠 High (17 files)
🟡 Medium (2 files)
🟢 Low (1 file)
AnalysisThis is a backport of a However, the PR also touches To override, add a |
Verifying the regenerated stubs against masterCommit 2 is the one part of this PR that can't be reviewed by reading it, so Wherever a Result:
No differences on either branch. Four files here have protos that genuinely diverge from master, since master has Same string-constant Together with
So the ~16k deleted lines in commit 2 are the |
c0e4751
into
lightningnetwork:v0.20.x-branch
3 participants
Backport of #11105 to
v0.20.x-branch. Companion to #11109 (v0.21.x).Opened manually rather than via the backport bot, which failed to push both
release branches for #11105 ("Git push to origin failed for v0.20.x-branch with
exitcode 1") — the change touches
.github/files.How this backport differs from #11105
This is not a verbatim replay. Mapping the source commits onto this branch:
ad7ccc004build: bump grpc to v1.83.1029045649(cherry-pick-x)go.mod/go.sumregenerated, not replayed — see below. CI pin resolved by hand (v1.59.0 → v1.83.1)81c3fb26bkvdb: bump grpc module floor8a23e33c2brontide: clarifyInitializeKeyinvariantb32c7d18f(cherry-pick-x)4b2602c73+30b08925e1.
go.mod/go.sumwere regenerated, not replayedv0.20.x is far enough behind master that the dependency commit conflicts. The
bump was reproduced on the branch with
go get google.golang.org/grpc@v1.83.1 && go mod tidyrather than importingmaster's files, which would have pulled in bumps belonging to unrelated master
PRs.
2. The
kvdbcommit is omitted as a no-opmaster carries
replace github.com/lightningnetwork/lnd/kvdb => ./kvdb, so theroot bump flows into the local module there. v0.20.x has no local sub-module
replaces and consumes published
kvdb, sogo mod tidyinkvdb/produces nochange at all.
This is safe beyond just being a no-op: kvdb exposes no gRPC server. It has no
grpc.NewServerand no service registration — grpc reaches it only as an etcdclient (
kvdb/etcd→etcd/api/v3/etcdserverpb→ grpc), behind thekvdb_etcdbuild tag, so it is not exposed to the server-side transportadvisories above. The shipped binary resolves grpc from the root module
regardless, and the
dep-pinCI job greps the rootgo.modonly.3. Two added commits: the protobuf prerequisite
master did not need this because it was already on protobuf v1.36.11. This
branch sits at v1.33.0, self-consistent across require, the hex-display replace
and the generated stubs.
grpc v1.83.1 requires
google.golang.org/protobuf v1.36.11, which is above thev1.33.0 pin, so MVS raises it. Because
lnrpc/gen_protos_docker.shderivesPROTOBUF_VERSIONfrom the selected protobuf version, that also dragsprotoc-gen-gofrom v1.33.0 to v1.36.11, andmake rpc-checkfails until thestubs are regenerated. The version cannot be held down — MVS takes the maximum
of all requirements.
Rather than leave that churn tangled into the grpc commit, it is done up front
as its own prerequisite, in the order master landed it (
3f3718caa, #10887).These two commits are authored fresh rather than cherry-picked: master's
equivalent moved v1.36.10 → v1.36.11, so replaying it here would be wrong.
Commit structure
mod: bump protobuf hex display forkv1.36.11-hex-displaylnrpc: bump protobuf to v1.36.11 and regenerate stubsbuild: bump grpc to v1.83.1brontide: clarify InitializeKey error-discard invariantx/cryptobumpThe ordering is deliberate, and reviewing commit 3 in isolation is the point:
because protobuf has already reached v1.36.11 by then, the security fix touches
only
go.mod,go.sumand the CI pin, with no generated code at all. Allthe noise is quarantined in commit 2, under a title that says what it is.
Splitting the fork bump (1) from the require bump (2) also keeps the skew
pointing the right way. Commit 1 moves only the runtime, so protobuf is ahead
of the generated code — the supported direction — and since the generator
version comes from the required version, it stays at v1.33.0 and the stubs do
not move. Commit 2 then brings require and stubs up together.
The result is that every commit is internally consistent, so
make rpc-checkisclean at each one rather than only at the tip:
rpc-check4b2602c7330b08925e029045649b32c7d18fEvery commit also builds independently.
On the size of commit 2
The diff is large but mechanical: the v1.36 generator emits each file descriptor
as a string constant instead of a
[]byteliteral, which accounts for nearlyall of it — hence ~6.8k insertions against ~16.4k deletions. No
.protofile istouched and no RPC definition changes. The output matches the generator form
master already carries, and
make rpcis idempotent against the committedstubs.
Steps to Test
go build ./...go vet ./brontide/... ./lnrpc/...go test ./lnrpc/... ./brontide/...make rpcleaves the tree clean, somake rpc-checkpassesgo mod tidyproduces no drift ingo.mod/go.sumPull Request Checklist
Testing
Code Style and Documentation
no-changeloglabel applied.