feat: enable CGO cross-compilation using gythialy/golang-cross

[sampras343]

Summary

• Enable CGO_ENABLED=1 across all build paths (Dockerfile.rh, Dockerfile.tufcli-init, Build.mak) to support features requiring CGO
• Swap the CLI stack cross-platform build stage (Dockerfile.cli-stack.rh) from UBI9 go-toolset to ghcr.io/gythialy/golang-cross:v1.26.4-0, which bundles osxcross (macOS) and mingw-w64 (Windows) cross-compiler toolchains
• Add per-target CC/CXX in Build.mak: oa64-clang (darwin/arm64), o64-clang (darwin/amd64), x86_64-w64-mingw32-gcc (windows/amd64)
• FIPS settings preserved: GOFIPS140=v1.0.0, -tags=no_openssl, fips140=auto godebug unchanged
• Linux multi-arch builds unchanged — continue to compile natively on each Konflux arch node

Test plan

• Verify make build succeeds locally with CGO enabled
• Verify docker build -f Dockerfile.rh . builds successfully
• Verify docker build -f Dockerfile.tufcli-init . builds successfully
• Verify docker build --target build-cross-platform -f Dockerfile.cli-stack.rh . pulls golang-cross and cross-compiles all 3 targets
• Verify Tekton PR pipeline passes (lint, tests)
• Verify FIPS compliance is unaffected

[qodo-for-securesign]

PR Summary by Qodo

Enable CGO cross-compilation via gythialy/golang-cross (macOS + Windows)

✨ Enhancement ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Enable CGO across Docker and Make build paths to unblock CGO-dependent features.
• Switch cross-platform builder stage to golang-cross (osxcross + mingw-w64) for macOS/Windows.
• Add per-target CC/CXX toolchain selection while preserving existing FIPS build settings.

Diagram

graph TD
  A["Dockerfile.cli-stack.rh"] --> B(["golang-cross image"]) --> C["make cross-platform"] --> D["Build.mak"] --> E["tufcli darwin/win"]
  F["Dockerfile.rh & tufcli-init"] --> G["CGO_ENABLED=1"] --> H["native Go build"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep UBI go-toolset and install cross toolchains in Dockerfile

• ➕ Avoids reliance on a third-party builder image
• ➕ Keeps the builder aligned with Red Hat UBI base for supply-chain expectations
• ➖ Higher maintenance (install scripts, pinned toolchain versions, CVE patching)
• ➖ Longer build times and more fragile setup (osxcross dependencies, SDK handling)

2. Per-target dedicated builders (one image per OS/arch toolchain)

• ➕ Clear isolation of toolchains and dependencies per target
• ➕ Easier to version/pin and troubleshoot one target at a time
• ➖ More images/stages to maintain
• ➖ More CI wiring and potential duplication across stages

3. Use zig as the C compiler for Go cross-compilation

• ➕ Often simplifies cross-compiling CGO without OS-specific toolchains
• ➕ Can reduce dependency on Apple/MinGW-specific tooling
• ➖ May not match existing expectations for macOS/Windows ABI/toolchain quirks
• ➖ Potential incompatibilities or extra validation needed for current CGO usage

Recommendation: The chosen approach (golang-cross) is a pragmatic middle ground: it centralizes the macOS/Windows cross toolchains in a purpose-built image and keeps the Makefile changes explicit (CC/CXX per target). Given the stated requirement to support CGO features across all build paths, this is likely the lowest ongoing maintenance option versus hand-installing osxcross/mingw in UBI.

Files changed (4) +11 / -15

Other (4) +11 / -15

Build.makEnable CGO and set per-target cross-compilers for darwin/windows +3/-3

Enable CGO and set per-target cross-compilers for darwin/windows

• Switches macOS and Windows build targets from CGO_DISABLED to CGO_ENABLED. Adds explicit CC/CXX selections (oa64-clang/o64-clang for macOS, mingw-w64 gcc/g++ for Windows) while keeping existing GOFIPS140 and build tags intact.

Build.mak

Dockerfile.cli-stack.rhUse golang-cross builder stage and update build/copy paths +6/-10

Use golang-cross builder stage and update build/copy paths

• Replaces the UBI9 go-toolset cross-platform build stage with ghcr.io/gythialy/golang-cross to supply osxcross and mingw-w64. Updates WORKDIR and safe.directory configuration, and adjusts COPY paths for the produced cross-compiled binaries.

Dockerfile.cli-stack.rh

Dockerfile.rhEnable CGO for the container build path +1/-1

Enable CGO for the container build path

• Flips CGO_ENABLED from 0 to 1 while preserving the existing GOFIPS140 setting and FIPS godebug configuration.

Dockerfile.rh

Dockerfile.tufcli-initEnable CGO for the tufcli-init container build path +1/-1

Enable CGO for the tufcli-init container build path

• Flips CGO_ENABLED from 0 to 1 while preserving the existing GOFIPS140 setting and FIPS godebug configuration.

Dockerfile.tufcli-init

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.14%. Comparing base (49c9db5) to head (617f400).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #43      +/-   ##
==========================================
+ Coverage   74.47%   76.14%   +1.67%     
==========================================
  Files          22       27       +5     
  Lines        2268     3215     +947     
==========================================
+ Hits         1689     2448     +759     
- Misses        305      402      +97     
- Partials      274      365      +91     

Flag	Coverage Δ
unit	76.14% <ø> (+1.67%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[qodo-for-securesign]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unpinned golang-cross base image ✓ Resolved 🐞 Bug ⛨ Security

Description

Dockerfile.cli-stack.rh now pulls ghcr.io/gythialy/golang-cross by mutable tag only, making builds
non-reproducible and weakening supply-chain integrity. This is inconsistent with the rest of the
Dockerfile which pins images by sha256 digest.

Code

Dockerfile.cli-stack.rh[1]

+FROM ghcr.io/gythialy/golang-cross:v1.26.4-0 AS build-cross-platform

Relevance

●●● Strong

Repo already pins Dockerfile.cli-stack.rh images by digest; unpinned new base is inconsistent and
likely to be fixed.

PR-#30
PR-#31

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new cross-platform build stage uses a mutable tag, while the other stages in the same Dockerfile
use immutable digests, demonstrating an inconsistency that reduces reproducibility.

Dockerfile.cli-stack.rh[1-16]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`Dockerfile.cli-stack.rh` uses a tag-only `FROM ghcr.io/gythialy/golang-cross:v1.26.4-0`, which can change over time and make builds non-reproducible.

### Issue Context
Other images in the same Dockerfile are already pinned with `@sha256:...`, indicating the build is intended to be deterministic.

### Fix Focus Areas
- Dockerfile.cli-stack.rh[1-1]

### Suggested fix
- Resolve `ghcr.io/gythialy/golang-cross:v1.26.4-0` to its immutable digest and update the line to:
 - `FROM ghcr.io/gythialy/golang-cross@sha256:<digest> AS build-cross-platform`
- (Optional) If you also need platform pinning, combine with the platform fix from the other finding.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Cross-build stage platform unspecified ✓ Resolved 🐞 Bug ☼ Reliability

Description

The build-cross-platform stage omits --platform, so in multi-platform BuildKit builds it will be
instantiated per target platform rather than being forced onto a known builder platform. Since other
stages in this Dockerfile explicitly set --platform, this omission risks cross-build failures or
inconsistent behavior depending on which architectures the golang-cross image/toolchains support.

Code

Dockerfile.cli-stack.rh[R1-2]

+FROM ghcr.io/gythialy/golang-cross:v1.26.4-0 AS build-cross-platform
+WORKDIR /build

Relevance

●●● Strong

Multi-platform support was added recently; Dockerfile.cli-stack.rh already uses explicit --platform
in other stages.

PR-#30
PR-#31

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Dockerfile explicitly sets platform for the Linux build stages but not for the cross-platform
stage, demonstrating a platform-selection inconsistency introduced by the PR change.

Dockerfile.cli-stack.rh[1-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`build-cross-platform` has no `--platform` qualifier, which can cause it to run on each target platform in a multi-arch build and potentially fail if the cross-toolchain image is not intended for all target architectures.

### Issue Context
This Dockerfile already uses explicit `--platform=...` for the native Linux binary stages, suggesting platform determinism is expected.

### Fix Focus Areas
- Dockerfile.cli-stack.rh[1-2]

### Suggested fix
- Decide the intended execution platform for the cross-toolchain stage and set it explicitly, for example:
 - `FROM --platform=$BUILDPLATFORM ghcr.io/gythialy/golang-cross@sha256:<digest> AS build-cross-platform`
 - or if you specifically require amd64 toolchains: `FROM --platform=linux/amd64 ...`
- Keep the existing per-arch Linux stages as-is.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}