Export GOFIPS140 to the remaining Go component builds

What does this MR do?

Under USE_GO_FIPS_MODULE, only four recipes export GOFIPS140: gitaly, gitlab-pages, gitlab-rails, and gitlab-shell. The registry, gitlab-kas, and gitlab-elasticsearch-indexer recipes do not. Those three binaries compile with standard Go crypto inside a FIPS package. The builder images ship stock upstream Go, so the toolchain does not supply the module on its own.

This MR applies the existing pattern to the three remaining recipes:

env['GOFIPS140'] = Build::Check.go_fips_module_version if Build::Check.use_go_fips_module?

Build::Check.use_go_fips_module? includes the use_system_ssl? check, so the line is inert for all non-FIPS builds and for FIPS builds without the toggle.

It also sets FIPS_MODE=1 for gitlab-kas, which every other Go recipe in a FIPS build already did. gitlab-kas's Makefile turns that into -tags fips, and its own build/verify_fips_binary.sh asserts on that tag alongside GOFIPS140; without it, an omnibus-built kas fails upstream's verification even with the crypto module selected. The tag only gates agentk code the kas binary does not link, so the effect on what we ship is metadata.

Evidence of the gap

The empirical toggle run on current master shows GOFIPS140="v1.0.0" in the build environment of exactly the four in-scope components, and not the other three: https://gitlab.com/gitlab-org/omnibus-gitlab/-/jobs/16399836115

Verification

Important

Packages built by this MR's own pipeline have the toggle OFF, by design. USE_GO_FIPS_MODULE is forwarded to child pipelines by .base-trigger-job-variables, which needs a manual/API pipeline variable on the parent to expand. This MR's pipeline has none, so its Trigger:ee-package → build-package-on-all-os descendants build on the _fips (golang-fips) images with the toggle at its variables.yml default. Do not use those packages to check this change — the job names are identical in both pipeline trees.

The toggle harness is a separate branch pipeline (not reachable from the MR's pipeline widget), run with USE_GO_FIPS_MODULE=true and FIPS_BUILDER_IMAGE_SUFFIX="":

run	parent	Trigger:ee-package child	build-package-on-all-os grandchild
on 45de1693	2837192389	2837207198 — Ubuntu-22.04-fips-branch	2837218412 — AlmaLinux-9-fips-branch, AlmaLinux 8, AmazonLinux 2023
on 7d823127	2841523034

Both FIPS package jobs on 45de1693 ran on the base builder images and show GOFIPS140="v1.0.0" in the build environment of all seven Go components: gitaly, gitlab-rails (workhorse), gitlab-shell, gitlab-pages, and — new with this MR — registry, gitlab-kas, and gitlab-elasticsearch-indexer. AlmaLinux-9-fips-branch only exists in the build-package-on-all-os grandchild, because .fips_branch_template excludes TRIGGERED_(CE|EE)_PIPELINE.

Checking a package

Package artifacts expire after 1 day, so use a job from a recent harness run. On an installed package:

go version -m /opt/gitlab/embedded/bin/registry | grep -E 'GOFIPS140|fips140='
# or, without a Go toolchain:
readelf -p .go.buildinfo /opt/gitlab/embedded/bin/registry | grep GOFIPS140

Expect build GOFIPS140=v1.0.0-<hash> plus DefaultGODEBUG=...fips140=on. A toggle-off build shows neither — only vcs.revision. Note that go tool nm | grep -c crypto/internal/fips140 is not a detector: the package tree is linked in either way (~650 symbols in both).

Each of the three components was also replicated against its real upstream Makefile in a container, confirming the recipe's env: hash survives into go build (details: !9771 (comment 3822693676)).

Closes #10090 (closed)

Related to #10002 (closed)

Checklist

See Definition of done.

• Change is as small as possible
• All builds are passing
• Validated end-to-end on a real FIPS package build