feat(akhq): bump deps to remediate GHSA-j288-q9x7-2f5v and GHSA-xwmg-2g98-w7v9 and upgrade package

[efbar]

Signed-off-by: Francesco Bartolini francesco.bartolini@chainguard.dev

Bump deps to remediate GHSA-j288-q9x7-2f5v and GHSA-xwmg-2g98-w7v9

[octo-sts]

🩹 Build Failed: Patch Application Failed

Hunk #3 FAILED at 141. 1 out of 4 hunks FAILED -- saving rejects to file build.gradle.rej

Build Details

Category	Details
Build System	Gradle
Failure Point	patch '-p1' --fuzz=2 --verbose <cves-20250220.patch

Root Cause Analysis 🔍

The build failed because a patch file (likely cves-20250220.patch) could not be applied successfully to build.gradle. Specifically, hunk #3 failed at line 141. This suggests that the patch file doesn't match the current state of the code, possibly because the target file has been modified since the patch was created.

---

🔍 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

• Adding VersionStream for kafka-4.0 #48244

Suggested Changes

File: cves-20250220.patch

• replace (Update the entire patch file)
  Original:

The existing patch file that's failing to apply

Replacement:

Create an updated patch based on the current build.gradle file

Content:

To fix this issue, you need to regenerate the cves-20250220.patch file to match the current state of the build.gradle file. First, check out the repository at the expected commit (a39a1d0d4af145e9cd4f72399f919bb36b9900a0), then examine the rejected patch hunk (build.gradle.rej) to understand what changes were intended. Then create a new patch file that applies those same changes but against the current state of build.gradle.

File: akhq.yaml

• modify at line 22-24 (pipeline section, patch step)
  Original:

  - uses: patch
    with:
      patches: |
        cves-20250220.patch cves-20250530.patch cves-20250714.patch

Replacement:

  - uses: patch
    with:
      patches: |
        cves-20250220.patch cves-20250530.patch cves-20250714.patch
      fuzz: 3

Content:

Add the fuzz parameter to the patch step to increase the likelihood of successful patch application by allowing more context mismatch.

Click to expand fix analysis

Analysis

The build failure shows a patch application error where hunk #3 of the cves-20250220.patch file failed to apply at line 141 in build.gradle. This is similar to the fixed build failure example where a patch couldn't be applied cleanly to a gradle file. In the example fix, rather than trying to modify the existing patch, the approach was to create a completely new package definition file (kafka-4.0.yaml) that handled the package differently. Looking at the pattern, when patches fail to apply cleanly, it's typically because:

1. The target file content has changed since the patch was created
2. The line numbers or context in the patch don't match the current file
3. The patch was created for a different version of the software

Since the error specifically mentions "saving rejects to file build.gradle.rej", we know that the patch cannot be applied as-is to the current version of the repository. The best approach is to update the patch file to match the current state of the codebase.

Click to expand fix explanation

Explanation

The build failure occurs because the patch file (cves-20250220.patch) doesn't match the current state of the build.gradle file at line 141. This is a common issue when upstream repositories evolve and the patches we maintain no longer apply cleanly.

There are two main approaches to fix this:

1. Update the patch file to match the current state of the build.gradle file:

   • Examine the build.gradle.rej file that was generated during the failed build to see what changes weren't applied
   • Create a new patch that applies the same security fixes but works with the current file layout
   • This is the most thorough approach and ensures the security patches are properly applied

2. Increase the fuzz factor in the patch application:

   • Adding the "fuzz: 3" parameter allows the patch command to be more lenient in finding matching context
   • This can help when the file has only minor changes from what the patch expects
   • This is a quicker solution but carries some risk if the context has changed significantly

The suggested changes address both approaches. The ideal fix is to regenerate the patch file to match the current state of the repository, but increasing the fuzz factor may be a quicker temporary solution if the changes aren't too drastic.

Since security patches are critically important (as mentioned in the guiding principles), ensuring these CVE patches are properly applied is essential. The most reliable approach is to examine what security fixes the original patch was attempting to apply and create a new patch that applies those same fixes to the current version of the code.

Click to expand alternative approaches

Alternative Approaches

• Instead of patching at build time, consider vendoring a pre-patched version of the source code. This approach would involve forking the repository, applying the security patches, and then pointing the git-checkout step to your patched fork.
• Review if the CVEs being patched are still relevant for version 0.26.0. If the upstream project has already incorporated fixes for these vulnerabilities in version 0.26.0, the patches might be unnecessary.
• Apply patches individually with different fuzz factors rather than all at once. This would allow you to see which specific patch is causing the issue and focus on fixing just that one: '- uses: patch\n with:\n patches: cves-20250530.patch cves-20250714.patch\n- uses: patch\n with:\n patches: cves-20250220.patch\n fuzz: 3'

---

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

[efbar]

the only upgrade fails too: #58811