Question: Clarification on hermetic LLVM toolchain origin

[tsaarni]

Envoy recently switched to using a hermetic LLVM toolchain:

• Use bazel hermetic toolchain for llvm #39010
• bazel: Use hermetic toolchain for LLVM #39679

I may have missed some background discussion, but I’d appreciate more details about where the toolchain originates from.

My current understanding:

• Using a locally installed LLVM toolchain is no longer supported.
• Envoy now relies on the LLVM toolchain provided by the LLVM toolchain for Bazel project.
• These toolchains download prebuilt LLVM binaries from the official LLVM release page.
• The downloads are defined in https://github.com/bazel-contrib/toolchains_llvm/blob/master/toolchain/internal/llvm_distributions.bzl

Envoy’s currently selected toolchain is specified in here which point to LLVM 18.1.8. According to the llvm 18.1.8 release notes, these binaries are not from the LLVM project itself:

Volunteers make binaries for the LLVM project, which will be uploaded when they have had time to test and build these binaries. They might not be available directly or not at all for each release. We suggest
you use the binaries from your distribution or build your own if you rely on a specific platform or configuration.

I found some background on who built this specific binary in this LLVM Discourse post https://discourse.llvm.org/t/18-1-8-has-been-tagged/79726/10.

There was discussion in LLVM Discourse about improving binary-build transparency and security ("[RFC] Improve binary security"), and starting with LLVM 19, it seems CI-produced binaries are available.

Is my understanding correct?

[phlax]

the origin of the llvm binaries is exactly the same with the hermetic toolchain as it was for our old container

wrt llvm project's build process - i would agree that this is a questionable foundation for the industries compilation - as you say, ideally the build should be transparent and reproducible - and the ability to push binaries to their authoritative release pages should be massively restricted (ie to trusted ci)

using a locally installed llvm is possible - not sure if i would say supported as such by the envoy project, but we are trying to ensure it can work - there are a couple of known wrinkles that need to be ironed out there