build(llard): install LLVM 19 in the runtime image

[MeteorsLiu]

Install LLVM 19 in the llard runtime image so its cross-compilation toolchain can find Clang, LLD, and LLVM binary utilities.

The implementation includes:

• Configure the apt.llvm.org LLVM 19 repository for Debian Bookworm with a repository-scoped signing key.
• Install clang-19, lld-19, and llvm-19 alongside the existing build dependencies.
• Prepend /usr/lib/llvm-19/bin to the runtime PATH, making the unversioned tool names available to the existing non-root llard user.

Validation: isolated Debian 12 amd64 and arm64 toolchain installations passed tool discovery, C/C++ compilation and execution with LLD, and archive/symbol/strip operations as UID 10001. Initial local distribution downloads hit HTTP timeouts/502 responses; the successful checks used the same distribution's HTTPS repositories. The actual multi-architecture image build is running in GitHub Actions.

Companion formula CI change: xgo-dev/llarhub#527.

This supplies the tools required by LLARD cross-compilation in both published image architectures.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fennoai]

Review: LLVM 19 toolchain for the llard runtime image

This adds the LLVM 19 toolchain (clang-19 lld-19 llvm-19) to the llard runtime image via the official apt.llvm.org repo. The mechanics are solid:

• signed-by keyring instead of the deprecated apt-key, scoped to just this repo.
• curl --fail so a failed key fetch aborts the build rather than writing an error page.
• Single RUN layer, --no-install-recommends, and rm -rf /var/lib/apt/lists/* keep the layer lean.
• The ENV PATH="/usr/lib/llvm-19/bin:${PATH}" is correct and necessary — internal/crosscompile/c/llvm/toolchain.go resolves unversioned names (clang, clang++, llvm-ar, ld.lld) via exec.LookPath, and those symlinks live in /usr/lib/llvm-19/bin. So the toolchain is a genuine runtime dependency, not build-only bloat.

Two hardening items and one cross-file consistency item below. None are blocking.

Toolchain version drift with CI (Medium). This image now runs LLVM 19, but the CI that builds and exercises llard still installs LLVM 18, so the E2E suite validates a different compiler than production ships:

• .github/workflows/llard-cluster-e2e.yml:48-49 — clang-18 lld-18 llvm-18, PATH /usr/lib/llvm-18/bin (this job runs llard).
• .github/workflows/crosscompile-e2e.yml:39-40 and :345-346 — also LLVM 18 (lower priority; these mainly exercise the llar client).

Consider bumping the llard-related workflow(s) to LLVM 19 to match, or documenting the intentional split. Any build-behavior difference between LLVM 18 and 19 would go uncaught today.

[fennoai]

[P2] GPG key fetched without fingerprint verification

The LLVM signing key is downloaded over the network and written directly to the keyring with no verification of its fingerprint. That key becomes the root of trust for every package installed from the LLVM repo, so its authenticity rests entirely on TLS to apt.llvm.org (plus --location, which allows a redirected source). If that host, its CDN/DNS, or the TLS chain is compromised, a substituted key would let apt trust malicious clang-19/lld-19/llvm-19 packages.

Consider pinning the expected key fingerprint and verifying it after download (e.g. gpg --show-keys --with-fingerprint compared to a hardcoded value), failing the build on mismatch — or vendoring a known-good key copy into the build context.

[fennoai]

[P3] LLVM packages not version-pinned (reproducibility)

apt.llvm.org is a rolling snapshot repo, so clang-19 lld-19 llvm-19 are unpinned — two builds of the same commit can pull different patch versions over time, causing silent toolchain drift and non-reproducible images. If reproducible builds matter here, consider pinning exact versions (e.g. clang-19=1:19.1.x-...).