[WIP] Update go

[jkopriva]

No description provided.

[qodo-for-securesign]

PR Summary by Qodo

Bump golang-cross and securesign image digests

⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Bump validate-release workflow to use golang-cross v1.26.3 container image.
• Refresh pinned digests for securesign CLI/tool images in Dockerfile.clients.rh.

Diagram

graph TD
  repo["Repo"] --> wf["validate-release.yml"] --> goimg{{"golang-cross 1.26.3"}}
  repo --> df["Dockerfile.clients.rh"] --> out(["Clients RH image"])
  sec{{"Securesign images"}} --> df --> out
  rh{{"Red Hat base"}} --> df --> out

  subgraph Legend
    direction LR
    _cfg["Config/File"] ~~~ _ext{{"External image"}} ~~~ _art(["Built artifact"])
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Automate digest bumps with Renovate/Dependabot

• ➕ Reduces manual maintenance for frequent image digest updates
• ➕ Creates consistent PRs with changelogs/metadata and scheduling
• ➖ Adds bot/config overhead and occasional noisy PR cadence
• ➖ May need custom rules for multi-stage Dockerfile digests

2. Centralize image versions/digests into a single config file

• ➕ Single source of truth for image pins across workflows/Dockerfiles
• ➕ Easier reviews and coordinated upgrades
• ➖ Requires wiring templating/substitution into CI/build (extra moving parts)
• ➖ May be overkill if only a few files pin images

3. Pin by semantic tags (avoid digests)

• ➕ Simpler to read and update
• ➕ Avoids frequent digest-only churn
• ➖ Weakens supply-chain guarantees and reproducibility
• ➖ Risk of unexpected changes when tags move

Recommendation: Keeping digest-pinned images (as done here) is the right default for reproducible and supply-chain-safe builds. If these bumps are frequent, consider adding Renovate (or similar) to propose digest updates automatically, while retaining digest pinning.

Files changed (2) +8 / -8

Other (2) +8 / -8

validate-release.ymlBump validate-release job container to golang-cross v1.26.3 +1/-1

Bump validate-release job container to golang-cross v1.26.3

• Updates the GitHub Actions validate-release job to run inside a newer ghcr.io/gythialy/golang-cross image (version and digest). This refreshes the Go build environment used during release validation.

.github/workflows/validate-release.yml

Dockerfile.clients.rhRefresh pinned securesign tool image digests for RHEL clients build +7/-7

Refresh pinned securesign tool image digests for RHEL clients build

• Updates the pinned digests for multiple quay.io/securesign images used as multi-stage build inputs (cosign, gitsign, fetch-tsa-certs, rekor-cli, trillian tools, tuftool). This keeps the resulting clients image aligned with the latest snapshot artifacts while preserving digest pinning.

Dockerfile.clients.rh

[qodo-for-securesign]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Signature check drift 🐞 Bug ⛨ Security

Description

In .github/workflows/validate-release.yml, validate-release-job now runs inside
ghcr.io/gythialy/golang-cross:v1.26.3-0@..., but the check-signature job still verifies the
signature and identity for the older v1.25.1-0@... image. This means the workflow can pass while
never verifying the provenance/signature of the actual container image used to build the snapshot.

Code

.github/workflows/validate-release.yml[46]

+      image: ghcr.io/gythialy/golang-cross:v1.26.3-0@sha256:9f7a53d7205e2f1f2742d624ff0b6e1531e8c22863dfb24ca966be5efbdee48b

Evidence

The workflow’s signature verification step is still pinned to v1.25.1-0 while the job container
image was bumped to v1.26.3-0, so the signature check no longer validates the image that executes
the build.

.github/workflows/validate-release.yml[26-37]
.github/workflows/validate-release.yml[40-47]

Agent prompt

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

### Issue description
The workflow verifies `golang-cross` image **v1.25.1-0** in the `check-signature` job, but the actual build job (`validate-release-job`) runs using **v1.26.3-0**. This breaks the intent of the signature gate.

### Issue Context
`check-signature` must verify the same image digest/tag that will be used by `validate-release-job`, including updating the `--certificate-identity` reference.

### Fix Focus Areas
- .github/workflows/validate-release.yml[26-47]

### Suggested change
- Update the `cosign verify` target image (tag+digest) to `v1.26.3-0@sha256:9f7a...`.
- Update `--certificate-identity` to reference `refs/tags/v1.26.3-0`.
- (Optional, to prevent future drift) define a single env var (e.g. `GOLANG_CROSS_IMAGE`) and reuse it in both `check-signature` and `validate-release-job.container.image`.

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

---

[qodo-for-securesign]

1. Signature check drift 🐞 Bug ⛨ Security

In .github/workflows/validate-release.yml, validate-release-job now runs inside
ghcr.io/gythialy/golang-cross:v1.26.3-0@..., but the check-signature job still verifies the
signature and identity for the older v1.25.1-0@... image. This means the workflow can pass while
never verifying the provenance/signature of the actual container image used to build the snapshot.

Agent Prompt

### Issue description
The workflow verifies `golang-cross` image **v1.25.1-0** in the `check-signature` job, but the actual build job (`validate-release-job`) runs using **v1.26.3-0**. This breaks the intent of the signature gate.

### Issue Context
`check-signature` must verify the same image digest/tag that will be used by `validate-release-job`, including updating the `--certificate-identity` reference.

### Fix Focus Areas
- .github/workflows/validate-release.yml[26-47]

### Suggested change
- Update the `cosign verify` target image (tag+digest) to `v1.26.3-0@sha256:9f7a...`.
- Update `--certificate-identity` to reference `refs/tags/v1.26.3-0`.
- (Optional, to prevent future drift) define a single env var (e.g. `GOLANG_CROSS_IMAGE`) and reuse it in both `check-signature` and `validate-release-job.container.image`.

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