Bazel: provide pre-built binary toolchain for protoc

[alexeagle]

From https://protobuf.dev/news/2024-10-01/#end-goal:

Once the rules are in the protobuf repo, we intend to address common user requests, such as using prebuilts for the proto compiler where possible.

This is that request.

What language does this apply to?
All

Describe the problem you are trying to solve.

All Bazel users are expected to build protoc from source as a cc_binary. This leads to problems which are often reported on the Bazel Slack:

1. Bazel doesn't include a hermetic C++ toolchain, so the compilation fails for a subset of developers due to the host toolchain on their computer. This can be easily reproduced by registering a non-functional toolchain. Many users have no C++ code, so they have no benefit from dealing with this hermeticity failure other than to repair protoc.
2. protoc frequently gets recompiled rather than being a cache hit - example report, issue. This makes Bazel builds slow.

Describe the solution you'd like

Bazel's toolchain feature allows it to download the pre-built binaries from protobuf releases

bazelbuild/rules_proto#205 was part of my earlier work to provide this capability. The ruleset mirrors its own integrity hashes as part of each release.

https://github.com/aspect-build/toolchains_protoc/ is a user-land implementation of this proposal, however it was broken by changes in Bazel 8 and rules_proto described by https://protobuf.dev/news/2024-10-01/.

Additional context
Some user reports:

• https://fzakaria.com/2024/11/28/bazel-knowledge-protobuf-is-the-worst-when-it-should-be-the-best.html

I describe some GitHub Actions workflows for automating this pattern on https://blog.aspect.build/releasing-bazel-rulesets-rust (and the earlier https://blog.aspect.build/releasing-bazel-rulesets)

[shaod2]

Yes, we have changes pending to provide prebuilt protocs in the open source realm. I don't have the exact timeline tho; currently expecting for H1 2025

[vorburger]

Having to constantly rebuild protoc from scratch everywhere causes all sorts of weird surprises; e.g. grpc/grpc-java#11790!

It also makes builds more "heavy" than they could otherwise be, which is a problem in certain more "light" (lite?) build environments; note e.g. jitpack/jitpack.io#3129.

It would be really cool if using Protocol Buffers with Bazel would no longer require building protoc.

[mering]

In setups with RBE available, this is not a problem since it is mostly just downloaded from the remote cache anyways. In fact, in such setups it is usually preferred to build from source instead of downloading random binaries from the internet for compliance reasons. So building from source should definitely be kept as an option and downloading pre built binaries should be optional.

[vorburger]

In setups with RBE available, this is not a problem since it is mostly just downloaded from the remote cache anyways.

Sure, but not every user of Protobuf of Bazel has RBE set-up for every project.

In fact, in such setups it is usually preferred to build from source instead of downloading random binaries from the internet for compliance reasons.

This can of course easily be solved with some sort of checksum / hash that's verified on the download; à la http_archive's sha256 or the HTML's Subresource Integrity (SRI) or that ?hl= "standard" idea for Cryptographic Hyperlinks from draft-sporny-hashlink-07 (what a shame that never gained more widespread traction) et al.

So building from source should definitely be kept as an option and downloading pre built binaries should be optional.

An "opt in" flag (?) would already be a huge progress over the current situation!

[mering]

This can of course easily be solved with some sort of checksum / hash that's verified on the download; à la http_archive's sha256 or the HTML's Subresource Integrity (SRI) or that ?hl= "standard" idea for Cryptographic Hyperlinks from draft-sporny-hashlink-07 (what a shame that never gained more widespread traction) et al.

This is only a small part of the story. How do you verify that the binary doesn't contain malicious code? You need reproducible builds first. Then you need to build from source and verify that the binary you download is actually the artifact built from the source you are expecting. You need to do this for every version as inspecting binary diffs is not handy. When you build from source, you only need to check the source diff which is much easier to review.
Dependency attacks are a thing. This is how companies get hacked.

[alexeagle]

@mering yes, supply chain security is an important consideration here, both under Bazel and any other build system.

I think you're pointing out #16165 again - since protoc downloads aren't provided along with a checksum, users have to compute one themselves. Any Bazel rules that fetch should include a checksum - this is true whether they fetch sources and then compile them, or a binary that's compiled by someone else. https://github.com/aspect-build/toolchains_protoc/blob/main/protoc/private/versions.bzl#L54 for example.

Then yes, it would be nice to have a proof of provenance, via some attestation published on protoc releases. We are adding these right now to modules on the BCR. It will be trivial for tools like tar where we use GitHub Actions and they have a feature for this.

setups with RBE available, this is not a problem

This isn't true for most Bazel users, since they ship Macs to their developers and the remote cache contains Linux binaries only.