pprof now installed in profiling-deps images

[marc-casavant]

A minor change made to the profiling images. pprof is now installed as part of the profiling-deps* images. All associated Dockerfiles also updated.

Update verified locally by running make test.multi-server.ldap.short_ci MODE=profiling. Build and profiling test working as expected.

[claude]

I reviewed this PR and didn't find any bugs. Because it introduces a new external supply-chain step (downloading and installing a pinned Go toolchain plus a pinned pprof commit, with hardcoded sha256 checksums) into every profiling-deps image, a human look would still be worthwhile.

What was reviewed: the new Go-toolchain-download-and-pprof-install RUN step added identically to profiling-deps.deb.m4 and profiling-deps.rpm.m4; confirmed the GO_SHA256_AMD64/ARM64 values and PPROF_COMMIT are correctly-sized hex strings (64/64/40 chars); confirmed the five generated per-OS Dockerfile.profiling-deps files stay byte-for-byte in sync with their m4 templates; and reviewed the comment-only doc updates in dockerfile.mk, the refresh workflow, and profiling.deb.m4/profiling.rpm.m4.

Extended reasoning...

Overview

This PR adds a new RUN layer to the .deb and .rpm profiling-deps m4 templates that downloads a pinned Go toolchain, verifies it via sha256, uses it to go install a pinned commit of github.com/google/pprof, and then removes the Go toolchain to keep the image slim. It also updates comment text (gperftools rationale, tool lists) in dockerfile.mk, the refresh workflow, and profiling.deb.m4/profiling.rpm.m4. All five per-OS generated Dockerfile.profiling-deps files were regenerated and verified byte-identical in intent to their m4 sources.

Security risks

The main supply-chain-relevant surface is the new curl-download-and-checksum-verify step for the Go toolchain (fetched over HTTPS with --proto '=https' --tlsv1.2, verified against a hardcoded sha256) and the go install of a pinned pprof commit (not sha-verified beyond Go's own module checksum database, which is standard practice for go install @ commit). I manually double-checked the length of the two hardcoded sha256 values and the pprof commit hash via regex matching; they are correctly formatted (64 hex chars for the sha256 values, 40 hex chars for the git commit). I did not independently verify these hashes/commit against Google's actual published values (no network access in this sandboxed check), but the pinning approach itself is sound and matches the existing pattern used for cargo/inferno installs earlier in the same file.

Level of scrutiny

This is a Docker build/tooling change confined to CI/profiling image generation — it does not touch FreeRADIUS server code, protocol handling, or auth/crypto paths. The change is mechanical and follows the existing pattern in the file (similar to the pre-existing rustup/cargo install block). That said, adding a new external binary download with hardcoded checksums to a build pipeline is exactly the kind of change where a second set of eyes checking the actual checksum values against upstream is valuable, since an incorrect checksum would only ever fail loudly (safe direction) but a checksum that was accidentally computed against the wrong artifact would not be caught by this review.

Other factors

The bug hunter's candidate list flagged the hard exit 1 on unsupported architectures and the fact that arm64 is never exercised by CI — both are minor, arguably intentional design choices (fail loudly rather than silently produce a broken image) rather than functional bugs, and were already left as inline candidates rather than being escalated as blocking. No CODEOWNERS/ANTOWNERS restrictions apply to these paths, and the PR author states they verified the change locally by running a full profiling-mode test.

[arr2036]

@claude, there's no package manager that could install pprof?

[claude]

Claude finished @arr2036's task in 2m 13s —— View job

---

Answer: is there a package manager that could install pprof?

• Read the install step in the m4 templates
• Work out what's actually packaged vs. not
• Answer

Short version: not for the tool this PR wants. There are two unrelated programs called pprof, and only the wrong one is packaged.

1. gperftools pprof — packaged, but it's the legacy Perl one

Debian/Ubuntu ship it in google-perftools as /usr/bin/google-pprof; Rocky/EPEL ship it in gperftools as /usr/bin/pprof. But this is the old Perl script, and the comment this PR deletes (profiling-deps.deb.m4:8-10 on master) already notes google-perftools has been retired from newer Debian/Ubuntu archives — so it isn't reliably installable across debian13 / debiansid / ubuntu24 / ubuntu26 anyway. And per the new comment at scripts/docker/m4/profiling-deps.deb.m4:54-55, it's not the one that produces the -proto output the profiling server ingests.

2. github.com/google/pprof (Go) — packaged only as a library

Distros package this for other Go packages to build against, not as a CLI:

• Debian/Ubuntu: golang-github-google-pprof-dev — installs Go source under /usr/share/gocode/src/github.com/google/pprof/, no /usr/bin/pprof.
• Fedora/EPEL: golang-github-google-pprof-devel — same shape.

Upstream publishes no binary releases and (as the comment notes) no tags at all, so go install …@<commit> is genuinely the sanctioned install path. Worth verifying on the actual bases before taking my word for it — I had no network access in this job:

apt-file search bin/pprof                 # debian13 / ubuntu24 / …
dnf repoquery --whatprovides '*/bin/pprof' --enablerepo='*'   # rocky9 / rocky10

What is packageable here: the Go toolchain

The part worth pushing back on isn't go install — it's the ~90 MB tarball fetch with two hardcoded sha256s and an arch case at profiling-deps.deb.m4:59-75 (and the identical block in the .rpm template plus five generated Dockerfiles). Two ways to delete all of that:

a) Distro Go + GOTOOLCHAIN. Since Go 1.21, GOTOOLCHAIN=auto is the default, so a distro Go that's older than pprof's go.mod requirement will transparently fetch the newer toolchain itself — the "pprof needs Go 1.25 or newer" note doesn't actually force the manual download:

RUN apt-get update && \
    apt-get install -y $APT_OPTS golang-go && \
    GOPATH=/tmp/gopath GOCACHE=/tmp/gocache GOBIN=/usr/local/bin \
    GOTOOLCHAIN=go1.27.1+auto CGO_ENABLED=0 \
        go install "github.com/google/pprof@${PPROF_COMMIT}" && \
    apt-get purge -y golang-go && apt-get autoremove -y && \
    apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/gopath /tmp/gocache

No checksums, no arch table, no GO_VERSION bump treadmill, and the toolchain is still pinned if you want it. Cost: needs the purge dance, and every target must have Go ≥ 1.21 (I believe ubuntu24 is 1.22 and debian13 is 1.24, so fine — worth confirming for rocky9, where you may want go-toolset rather than golang).

b) Multi-stage from the official Go image — cleanest, and this repo already uses multi-stage in service.deb.m4:2 / service.rpm.m4:47:

FROM golang:1.27 AS pprof
RUN CGO_ENABLED=0 GOBIN=/out go install github.com/google/pprof@${PPROF_COMMIT}
...
COPY --from=pprof /out/pprof /usr/local/bin/pprof

buildx picks the right arch on its own, so the x86_64/aarch64 case and the exit 1 fallback go away entirely, and nothing needs cleaning up out of the final layer.

One unrelated thing worth a look

doc/antora/modules/developers/pages/profile.adoc:40 documents pprof --cachegrind, and scripts/build/gprof-profile.sh:26 tells the user to brew install gperftools when pprof isn't on PATH. Both are gperftools-flavoured. The Go pprof accepts -text/-pdf/-gv, but the equivalent of --cachegrind there is -callgrind. If the intent is that the image's pprof is now the Go one, those two spots will mislead.

---

Answered only — no code changed. Happy to implement (a) or (b) across both m4 templates and regenerate the five Dockerfiles if you want to drop the pinned tarball.
• dev-marc-casavant/add-pprof-to-profiling-image