cluster-api-aws-controller/2.8.4-r0: cve remediation

[octo-sts]

cluster-api-aws-controller/2.8.4-r0: fix GHSA-hj57-j5cw-2mwp

Advisory data: https://github.com/wolfi-dev/advisories/blob/main/cluster-api-aws-controller.advisories.yaml

---

"Breadcrumbs" for this automated service

• Source Code: https://go/cve-remedy-automation-source
• Logs: https://go/cve-remedy-automation-logs
• Docs: (not provided yet)

[octo-sts]

🔢 Build Failed: Dependency Version Mismatch

go: github.com/coreos/[email protected]: invalid version: go.mod has post-v2 module path "github.com/coreos/ignition/v2" at revision v2.14.0

Build Details

Category	Details
Build System	Go/Melange
Failure Point	go/bump step during dependency update with gobump tool

Root Cause Analysis 🔍

The Go module github.com/coreos/ignition has a version mismatch issue where version v2.14.0 is being requested, but the go.mod file at that revision declares a post-v2 module path (github.com/coreos/ignition/v2). This violates Go module versioning semantics where major version v2+ must be included in the module path.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Similar PRs with fixes

• wolfictl/0.31.1-r0: cve remediation #47264

Suggested Changes

File: cluster-api-aws-controller.yaml

• modification at line 18-21 (pipeline go/bump step)
  Original:

  - uses: go/bump
    with:
      deps: |-
        github.com/coreos/[email protected]

Replacement:

  - uses: go/bump
    with:
      deps: |-
        github.com/coreos/ignition/[email protected]

Content:

Update the module path to include the /v2 suffix to match the semantic import versioning convention for major version 2+

Click to expand fix analysis

Analysis

The similar fix shows a clear pattern for handling Go module versioning issues with packages that have post-v2 module paths. In the containerd example, the fix involved updating the go/bump step to specify both the legacy module path (github.com/containerd/[email protected]) and the correct v2+ module path (github.com/containerd/containerd/[email protected]). This approach allows the build system to properly resolve dependencies when a package has migrated to semantic import versioning for major versions v2+.

Click to expand fix explanation

Explanation

The fix addresses the root cause of the Go module versioning error by updating the dependency specification to use the correct module path. When the coreos/ignition project migrated to version 2.x, they followed Go's semantic import versioning convention which requires major versions v2+ to include the version suffix in the module path. The error occurs because the go.mod file at revision v2.14.0 declares the module path as "github.com/coreos/ignition/v2", but the current dependency specification is requesting "github.com/coreos/[email protected]" without the /v2 suffix. By changing the dependency from "github.com/coreos/[email protected]" to "github.com/coreos/ignition/[email protected]", we align with the actual module path declared in the upstream go.mod file, allowing Go's module system to properly resolve the dependency.

Click to expand alternative approaches

Alternative Approaches

• Use a v1.x version of coreos/ignition if v2+ features are not required, though this may sacrifice security updates and new functionality
• Remove the explicit version bump and let the build process use whatever version is naturally resolved by go.mod, though this reduces reproducibility
• Use go mod replace directives in a custom go.mod if more complex dependency management is needed

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[kbsteere]

Superseded #61664