oscerd opened a new pull request, #736:
URL: https://github.com/apache/camel-karaf/pull/736
Addresses two of the three items in #731.
## 1. Pin the third-party action
`EnricoMi/publish-unit-test-result-action@v2` ->
`@d0a4676d0e0b938bc201470d88276b7c74c712b3 # v2.24.0`
`v2` is a mutable tag on a non-GitHub-authored action. It runs with
`if: always()` on `push` and `pull_request` under `checks: write`, after the
shared Maven cache is restored and before its post-step saves it. A
force-moved
tag changes what executes with no change landing in this repository, and
Dependabot cannot detect a tag that moves under it. Dependabot can still bump
the pinned SHA, which is the usual Apache infra arrangement.
The SHA is the commit `v2` currently resolves to, which is the `v2.24.0`
release.
## 2. Activate the checksum verification that already exists
`mvnw:254-281` and the wrapper jar both implement SHA-256 verification, but
the code was dormant because neither `wrapperSha256Sum` nor
`distributionSha256Sum` was set. Setting them turns the project's own
existing
mechanism on.
`wrapperSha256Sum` is worth having even though the jar is committed: `mvnw`
validates it against the local `maven-wrapper.jar`, so it covers tampering
with the 62 KB of opaque bytes in the repository, which no diff can show.
**Values were verified before pinning, not just computed:**
- the committed `.mvn/wrapper/maven-wrapper.jar` is **byte-identical** to
`maven-wrapper-3.2.0.jar` on Maven Central
(`e63a53cf…f52f066a`) -- so this pins a known-good jar, not whatever
happened
to be in the tree
- `apache-maven-3.9.6-bin.zip` fetched from Central has SHA-512 matching the
value published at `downloads.apache.org/maven/maven-3/3.9.6/binaries/`
exactly, so the SHA-256 recorded here (`83aaf914…c031625f`) is the ASF
artifact
**Both were then confirmed to actually enforce**, by corrupting each sum in
turn:
```
# corrupted wrapperSha256Sum
Error: Failed to validate Maven wrapper SHA-256, your Maven wrapper might be
compromised.
# corrupted distributionSha256Sum, with a clean MAVEN_USER_HOME to force
re-download
Exception in thread "main" java.lang.RuntimeException: Failed to validate
Maven
distribution SHA-256, your Maven distribution might be compromised.
```
and `./mvnw -v` runs normally with the committed values, both from cache and
from a fresh download.
## 3. Not done: removing the root `<repositories>` block
#731 also proposed dropping the Atlassian repository from the root POM on the
grounds that `components/camel-jira/pom.xml` already declares it for the only
artifacts that need it. **That is not correct and would break the build**,
so it
is left out of this PR:
- `features/src/main/feature/camel-features.xml:1996-2002` references
`com.atlassian.jira:jira-rest-java-client-{core,api}`,
`com.atlassian.sal:sal-api`, `com.atlassian.event:atlassian-event` and
`com.atlassian.httpclient:*` as feature bundles, and the `features` module
runs `karaf-maven-plugin:verify`, so it has to resolve them.
- `features/pom.xml` does **not** declare the Atlassian repository -- it
inherits it from the root.
- None of those artifacts are on Maven Central (all `404`), so there is no
fallback.
The narrower change that would achieve the original intent is to move the
declaration down to the two modules that actually need it
(`components/camel-jira`,
which already has it, plus `features`) rather than delete it. I have not done
that here because it wants a full reactor build to confirm nothing else in
the
tree resolves an Atlassian coordinate, and that is a separate change from the
two above. Details are in #731.
## Notes
No functional change to the build; CI on this PR exercises the pinned action.
---
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
