Conversation
Signed-off-by: Shawn Hurley <shawn@hurley.page>
📝 WalkthroughWalkthroughMaven is bumped from version 3.9.13 to 3.9.14 in both Dockerfile and Dockerfile.test, updating download URLs, installation paths, the M2_HOME environment variable, symlink targets, and COPY directives to reference the new version consistently. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip Migrating from UI to YAML configuration.Use the |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
Dockerfile.test (1)
35-35: Use a force-safe symlink for better rebuild resilience.At Line 35,
ln -scan fail if/usr/bin/mvnalready exists in a future base image update.ln -sfis safer.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile.test` at line 35, The symlink creation using "ln -s /usr/local/apache-maven-3.9.14/bin/mvn /usr/bin/mvn" can fail if /usr/bin/mvn already exists; change the command to use a force-safe symlink so rebuilds are resilient by using the force/overwrite flag with ln (i.e., replace the existing ln -s invocation that targets /usr/local/apache-maven-3.9.14/bin/mvn -> /usr/bin/mvn with a force-enabled ln command such as ln -sf) to ensure the symlink is created or replaced reliably during image builds.Dockerfile (1)
19-25: Consider centralizing Maven version/path to reduce future drift.The same Maven version/path is repeated across Line 19, Line 25, Line 47, Line 57, and Line 58. A single
ARG MAVEN_VERSION+ derived path reduces update mistakes; also preferln -sfat Line 58.Also applies to: 47-47, 57-58
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile` around lines 19 - 25, Introduce a build ARG like MAVEN_VERSION and derive a single MAVEN_DIR/MAVEN_BIN variable to centralize the Maven version/path (e.g., ARG MAVEN_VERSION=3.9.14 then compute /usr/local/apache-maven-${MAVEN_VERSION} and its bin), replace hardcoded occurrences of /usr/local/apache-maven-3.9.14/bin/mvn with the derived MAVEN_BIN variable, and create a stable symlink using ln -sf to point /usr/local/apache-maven to the versioned directory so future references can use the symlink; update the Dockerfile steps that download, extract, invoke mvn (the RUN curl ... tar ... and RUN .../bin/mvn clean install) and any other places that repeat the path to use these centralized variables/symlink.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfile`:
- Around line 19-21: The Dockerfile currently downloads and extracts Apache
Maven in RUN commands (the curl + tar sequence); update this to verify the
artifact using GPG signature verification before extraction: download both
apache-maven-3.9.14-bin.tar.gz and apache-maven-3.9.14-bin.tar.gz.asc,
import/verify with the official Apache Maven public keyring (or a pinned key
fingerprint) and only proceed to tar -xzf if gpg --verify succeeds;
alternatively or additionally validate against a pinned checksum stored in
source control and fail the build on mismatch so the RUN curl/tar sequence in
the Dockerfile is gated by GPG/checksum verification.
In `@Dockerfile.test`:
- Around line 33-37: The Dockerfile currently downloads and extracts
apache-maven in the RUN that creates /usr/local/apache-maven-3.9.14 and sets ENV
M2_HOME; add SHA512 integrity verification before extraction by downloading the
corresponding .sha512 (or .sha512.asc) file for apache-maven, verifying the
archive with sha512sum -c (or by comparing the checksum string) and failing the
build if the check does not pass, then only extract and remove artifacts when
verification succeeds; apply the same pattern to the other artifact download/run
blocks that fetch jdtls, intellij-community, and maven-search-index so each
archive is fetched, checksum-verified, and only then extracted/linked.
---
Nitpick comments:
In `@Dockerfile`:
- Around line 19-25: Introduce a build ARG like MAVEN_VERSION and derive a
single MAVEN_DIR/MAVEN_BIN variable to centralize the Maven version/path (e.g.,
ARG MAVEN_VERSION=3.9.14 then compute /usr/local/apache-maven-${MAVEN_VERSION}
and its bin), replace hardcoded occurrences of
/usr/local/apache-maven-3.9.14/bin/mvn with the derived MAVEN_BIN variable, and
create a stable symlink using ln -sf to point /usr/local/apache-maven to the
versioned directory so future references can use the symlink; update the
Dockerfile steps that download, extract, invoke mvn (the RUN curl ... tar ...
and RUN .../bin/mvn clean install) and any other places that repeat the path to
use these centralized variables/symlink.
In `@Dockerfile.test`:
- Line 35: The symlink creation using "ln -s
/usr/local/apache-maven-3.9.14/bin/mvn /usr/bin/mvn" can fail if /usr/bin/mvn
already exists; change the command to use a force-safe symlink so rebuilds are
resilient by using the force/overwrite flag with ln (i.e., replace the existing
ln -s invocation that targets /usr/local/apache-maven-3.9.14/bin/mvn ->
/usr/bin/mvn with a force-enabled ln command such as ln -sf) to ensure the
symlink is created or replaced reliably during image builds.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a9b1f0f8-6d82-445d-8cc7-09a623a5dd2a
📒 Files selected for processing (2)
DockerfileDockerfile.test
| RUN curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \ | ||
| tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \ | ||
| rm /tmp/apache-maven.tar.gz |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "Dockerfile" -type fRepository: konveyor/java-analyzer-bundle
Length of output: 175
🏁 Script executed:
cat -n ./Dockerfile | head -30Repository: konveyor/java-analyzer-bundle
Length of output: 2049
🌐 Web query:
Apache Maven 3.9.14 SHA512 checksum dlcdn.apache.org
💡 Result:
As of March 13, 2026, dlcdn.apache.org/maven/maven-3/ lists 3.9.13 as the latest 3.9.x release directory (no 3.9.14/ there yet). [1]
The SHA-512 values for the staged Apache Maven 3.9.14 binary archives (from the Apache Maven staging commit) are: [2]
-
apache-maven-3.9.14-bin.tar.gz
d50af8ab5e6005b46a07f0ce9d3719e67cfdf898da988a84871304cd59fb1af0fef2f99dea709e6e66f21f732f905979b5c2dce6b6860406f60a70e84d9cf0b8[2] -
apache-maven-3.9.14-bin.zip
4122c5e7a8794260539dd8fcd78480549511babff2f85e2b1258c8d4cf33c50af90f65d323f43c88d4959f35a8f37ced3eca802983caa6eb7cc81b16af936ab0[2]
Sources: [1] [2]
🌐 Web query:
dlcdn.apache.org maven 3.9.14 available download
💡 Result:
Yes—Apache Maven 3.9.14 is available on dlcdn.apache.org (directory present and updated 2026-03-12). [1]
Download from: [2]
https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.zip
https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz
Checksums/signatures (same folder): [2]
apache-maven-3.9.14-bin.zip.sha512
apache-maven-3.9.14-bin.zip.asc
apache-maven-3.9.14-bin.tar.gz.sha512
apache-maven-3.9.14-bin.tar.gz.asc
Sources: [1] (dlcdn.apache.org) [2] (dlcdn.apache.org)
Citations:
- 1: https://dlcdn.apache.org/maven/maven-3/
- 2: https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/
🌐 Web query:
sha512sum -c Docker checksum verification best practice supply chain
💡 Result:
When sha512sum -c is the right tool (and when it isn’t)
1) Inside a Dockerfile: verify downloaded build artifacts (good practice)
Use sha512sum -c (or sha256sum -c) to verify files you fetch with curl/wget during docker build (e.g., tarballs, CLIs). The common pattern is to embed the expected hash (or a checksum file) and fail the build if it doesn’t match. This is widely used as the “canonical” approach in Dockerfiles for integrity checking. [6]
Best-practice hardening (supply-chain):
- Don’t trust an unsigned checksum file downloaded from the same place as the artifact. If an attacker can swap the tarball, they can often swap the
.sha512too. Prefer:- a GPG-signed checksum file, or
- a checksum value sourced from a separately protected trust channel (release metadata in a signed repo, pinned in your own source control with review, etc.).
- Use
sha512sum --check --status(clean CI behavior) and make the build fail on any mismatch.
2) For Docker images: prefer digest pinning over sha512sum
For container images, the supply-chain best practice is to reference immutable image digests (e.g., image@sha256:...) rather than mutable tags (:latest, :1.2). Digests are explicitly positioned as an integrity / tamper-resistance control for images. [7]
3) For provenance + publisher identity: verify signatures/attestations (cosign / Notary)
A checksum only tells you “bits match,” not who produced those bits. For supply-chain security, add signature verification:
- cosign verification is the standard approach in the Sigstore ecosystem. [2]
- Docker also documents image validation policies and verification workflows that include digest checking and signature-based validation. [1]
- Docker Content Trust (Notary v1) is another signature mechanism focused on verifying publisher/integrity for signed tags. [8]
4) Enforce it, don’t just document it
In Kubernetes / runtime admission, many policies require images to be referenced by digest (and/or verified signatures) so deployments can’t “slip” to a different artifact later. Example policy guidance commonly fails images that aren’t pinned with @sha256:.... [1], [1]
Practical “best practice” checklist
- Dockerfile downloads:
sha512sum -c(orsha256sum -c) + ensure the expected hash is authenticated (signed metadata or protected channel). [6] - Base images / dependencies: pin
FROM repo/image@sha256:...(not just tags). [7] - Publisher/provenance: verify signatures (e.g.,
cosign verify ...) and consider attestations/provenance in policy. [2], [1] - Policy enforcement: enforce digest-pinning + signature verification in CI/admission control so it’s not optional. [1]
Verify Maven artifact integrity before extraction with GPG signature validation.
Line 19 downloads Maven and Line 20 extracts it directly without checksum or signature verification. This is a supply-chain risk in the build stage.
While downloading the .sha512 checksum file is an improvement, both the artifact and checksum come from the same source—if the CDN is compromised, both could be tampered with. For stronger assurance, verify the GPG signature (available at https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz.asc) against Apache Maven's public keys, or pre-download and pin the checksum in your source control as a separate, reviewed trust boundary.
Proposed hardening patch (with GPG signature verification)
-RUN curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \
- tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \
- rm /tmp/apache-maven.tar.gz
+RUN set -eux; \
+ curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \
+ curl -fsSL -o /tmp/apache-maven.tar.gz.asc https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz.asc && \
+ curl -fsSL https://www.apache.org/dist/maven/KEYS | gpg --import && \
+ gpg --verify /tmp/apache-maven.tar.gz.asc /tmp/apache-maven.tar.gz && \
+ tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \
+ rm -f /tmp/apache-maven.tar.gz /tmp/apache-maven.tar.gz.asc📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| RUN curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \ | |
| tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \ | |
| rm /tmp/apache-maven.tar.gz | |
| RUN set -eux; \ | |
| curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \ | |
| curl -fsSL -o /tmp/apache-maven.tar.gz.asc https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz.asc && \ | |
| curl -fsSL https://www.apache.org/dist/maven/KEYS | gpg --import && \ | |
| gpg --verify /tmp/apache-maven.tar.gz.asc /tmp/apache-maven.tar.gz && \ | |
| tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \ | |
| rm -f /tmp/apache-maven.tar.gz /tmp/apache-maven.tar.gz.asc |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile` around lines 19 - 21, The Dockerfile currently downloads and
extracts Apache Maven in RUN commands (the curl + tar sequence); update this to
verify the artifact using GPG signature verification before extraction: download
both apache-maven-3.9.14-bin.tar.gz and apache-maven-3.9.14-bin.tar.gz.asc,
import/verify with the official Apache Maven public keyring (or a pinned key
fingerprint) and only proceed to tar -xzf if gpg --verify succeeds;
alternatively or additionally validate against a pinned checksum stored in
source control and fail the build on mismatch so the RUN curl/tar sequence in
the Dockerfile is gated by GPG/checksum verification.
| RUN curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \ | ||
| tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \ | ||
| ln -s /usr/local/apache-maven-3.9.13/bin/mvn /usr/bin/mvn && \ | ||
| ln -s /usr/local/apache-maven-3.9.14/bin/mvn /usr/bin/mvn && \ | ||
| rm /tmp/apache-maven.tar.gz | ||
| ENV M2_HOME /usr/local/apache-maven-3.9.13 | ||
| ENV M2_HOME /usr/local/apache-maven-3.9.14 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
MVER="3.9.14"
BASE="https://dlcdn.apache.org/maven/maven-3/${MVER}/binaries"
curl -fsI "${BASE}/apache-maven-${MVER}-bin.tar.gz" >/dev/null
curl -fsI "${BASE}/apache-maven-${MVER}-bin.tar.gz.sha512" >/dev/nullRepository: konveyor/java-analyzer-bundle
Length of output: 55
🏁 Script executed:
git ls-files | grep -i dockerfileRepository: konveyor/java-analyzer-bundle
Length of output: 185
🏁 Script executed:
cat -n Dockerfile.test | sed -n '33,37p'Repository: konveyor/java-analyzer-bundle
Length of output: 441
🏁 Script executed:
cat -n Dockerfile.testRepository: konveyor/java-analyzer-bundle
Length of output: 3686
Add integrity verification for the downloaded Maven archive.
Line 33 downloads a remote tarball and line 34 extracts it without checksum/signature validation. This exposes the image to supply chain attacks through tampered artifacts. Implement SHA512 verification by downloading the checksum file and validating before extraction:
-RUN curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \
- tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \
- ln -s /usr/local/apache-maven-3.9.14/bin/mvn /usr/bin/mvn && \
- rm /tmp/apache-maven.tar.gz
+RUN set -eux; \
+ curl -fsSL -o /tmp/apache-maven.tar.gz https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz && \
+ curl -fsSL -o /tmp/apache-maven.tar.gz.sha512 https://dlcdn.apache.org/maven/maven-3/3.9.14/binaries/apache-maven-3.9.14-bin.tar.gz.sha512 && \
+ echo "$(cat /tmp/apache-maven.tar.gz.sha512) /tmp/apache-maven.tar.gz" | sha512sum -c - && \
+ tar -xzf /tmp/apache-maven.tar.gz -C /usr/local/ && \
+ ln -sf /usr/local/apache-maven-3.9.14/bin/mvn /usr/bin/mvn && \
+ rm -f /tmp/apache-maven.tar.gz /tmp/apache-maven.tar.gz.sha512Note: Similar integrity verification gaps exist for other artifact downloads in this file (jdtls, intellij-community, maven-search-index).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile.test` around lines 33 - 37, The Dockerfile currently downloads and
extracts apache-maven in the RUN that creates /usr/local/apache-maven-3.9.14 and
sets ENV M2_HOME; add SHA512 integrity verification before extraction by
downloading the corresponding .sha512 (or .sha512.asc) file for apache-maven,
verifying the archive with sha512sum -c (or by comparing the checksum string)
and failing the build if the check does not pass, then only extract and remove
artifacts when verification succeeds; apply the same pattern to the other
artifact download/run blocks that fetch jdtls, intellij-community, and
maven-search-index so each archive is fetched, checksum-verified, and only then
extracted/linked.
1 participant
Summary by CodeRabbit