Build failure with trillian@v1.7.2 and grpc@v1.79.3 (the latest versions)

[niels-moller]

Hi, I'm trying to update my deps to latest versions, including trillian and grpc. But I get a build failure. To reproduce, create a directory with the two files

go.mod:

module local

go 1.24.0

require (
	github.com/google/trillian v1.7.2
	google.golang.org/grpc v1.79.3
)

tools.go:

//go:build tools

package tools

import (
	_ "github.com/google/trillian/cmd/trillian_log_server"
	_ "google.golang.org/grpc"
)

In this directory, run go mod tidy followed by go install github.com/google/trillian/cmd/trillian_log_server. When I do this, it fails with this compile error:

# github.com/GoogleCloudPlatform/grpc-gcp-go/grpcgcp
../../../local/go/pkg/mod/github.com/!google!cloud!platform/grpc-gcp-go/grpcgcp@v1.5.2/gcp_balancer.go:40:27: cannot use (*gcpBalancer)(nil) (value of type *gcpBalancer) as balancer.Balancer value in variable declaration: *gcpBalancer does not implement balancer.Balancer (missing method ExitIdle)
../../../local/go/pkg/mod/github.com/!google!cloud!platform/grpc-gcp-go/grpcgcp@v1.5.2/gcp_balancer.go:86:9: cannot use gb (variable of type *gcpBalancer) as balancer.Balancer value in return statement: *gcpBalancer does not implement balancer.Balancer (missing method ExitIdle)

I don't have much clue about what's going on here, but it sounds like some incompatible change to some Balancer interface, probably only indirectly related to trillian. Is this a known problem?

From manual bisect on this example, it seems it works if I back down to grpc v1.73.1, but breaks with grpc v1.74.0.

An advice on how to deal with this?

[mhutchinson]

The core problem is that Go assumes all modules will honour semver properly, and grpc isn't released using standard semver rules. Thus when Go substitutes 1.74.0 in for 1.73.1, which should work according to semver, it doesn't work according to the compiler.

Can you use 1.73.1 for now, or do you need to use 1.74.0?

The solution will be to bump Trillian to this latest version of grpc. These bumps can be difficult because etcd also locks into grpc at a specific version, and thus they all need to be updated in lockstep. Sometimes this requires making code changes in Trillian to maintain the status quo.

[roger2hk]

Another workaround is to bump the trillian version to HEAD before v1.7.3 is release.

➜  tmp git:(master) ✗ go get github.com/google/trillian@master
go: downloading github.com/google/trillian v1.7.3-0.20260327122741-0288868db8ed
go: github.com/google/trillian@v1.7.3-0.20260327122741-0288868db8ed requires go >= 1.25.0; switching to go1.25.8
go: upgraded go 1.24.0 => 1.25.0
...
➜  tmp git:(master) ✗ go mod tidy                                                  
➜  tmp git:(master) ✗ go install github.com/google/trillian/cmd/trillian_log_server
➜  tmp git:(master) ✗ trillian_log_server
I0330 14:20:37.862831  726621 main.go:92] **** Log Server Starting ****
W0330 14:20:37.863110  726621 tree_storage.go:89] Failed to set strict mode on mysql db: dial tcp 127.0.0.1:3306: connect: connection refused
F0330 14:20:37.863143  726621 main.go:116] Failed to get storage provider: dial tcp 127.0.0.1:3306: connect: connection refused

[mhutchinson]

My last comment contains some truths, but I made the assumption that Trillian HEAD was behind. It's actually using the latest version of grpc. The problem is that the last tagged release is far behind.

I guess we should cut a new release of Trillian. It's almost been a year. We should merge in the pending bumps first

• Bump the go-deps group with 15 updates #3869 - @phbnf
• Bump the docker-deps group across 6 directories with 5 updates #3867 - @AlCutter

[niels-moller]

The core problem is that Go assumes all modules will honour semver properly, and grpc isn't released using standard semver rules. Thus when Go substitutes 1.74.0 in for 1.73.1, which should work according to semver, it doesn't work according to the compiler.

Ah, I didn't know grpc is weird in that way. We generally try (in a best-effort way) to keep all our deps close to latest version, to ensure we get security fixes etc. And we were lagging behind on grpc; I'm trying to update it from v1.71.0.

Can you use 1.73.1 for now, or do you need to use 1.74.0?

I think that should work fine. Is there some easy way to find out that 1.73.1 is an appropriate version for us? I think our only direct dependency on grpc is for grpc client apis (grpc.Dial etc) to connect to trillian.

[mhutchinson]

We'll cut a new release of Trillian now. @roger2hk is working on this 👍

[roger2hk]

I've just released v1.7.3. This should resolve the dependency conflict.

https://github.com/google/trillian/releases/tag/v1.7.3

[niels-moller]

Just an update from my side: At the moment, we're still on go-1.24 (we should probably update that reasonably soon; but the lack of any kind of "long term support" language version is causing us and debian packagers a bit of a headache). So we're now on trillian v1.7.2 and grpc v1.73.1, and that seems to work fine.

What would have helped me a bit is (i) if grpc did follow semantic versioning according to go conventions, or (ii) for the lack thereof, if that had been clearly documented somewhere where I looked. I don't know where to document that so that it will be discovered easily by a trillian user, but maybe trillian release notes could say "expected to work with grpc version X, but not later versions"?

Besides possibly documenting the grpc quirk, I see no further action needed on this issue.

[mhutchinson]

Thanks @niels-moller. Closing this as no more action needed for Trillian; it's in maintenance mode now.

I think you guys might adopt Tessera at some point. PTAL at transparency-dev/tessera#931 if you get the chance. I've described this issue, and how it could manifest over there, along with some steps to mitigate it by design.