oscerd opened a new pull request, #1816: URL: https://github.com/apache/camel-kafka-connector/pull/1816
Fixes #1804. Four independent gaps, small enough to do together. ## 1. Least-privilege token permissions Only `depsreview.yaml` declared a `permissions:` block, so every other workflow ran with the repository-default `GITHUB_TOKEN` scope. Declared per workflow, based on what each actually does: | Workflow | Permissions | Why | |---|---|---| | `ci-build.yml`, `daily-java-next.yml`, `maven-it.yaml` | `contents: read` | build and test only | | `asf-snapshots-deploy.yml` | `contents: read` | publishes to Nexus, not to GitHub | | `automatic-changelog-update.yml` | `contents: write` | pushes to `main` | | `automatic-sync-camel-main.yml`, `backport.yml` | `contents: write`, `pull-requests: write` | open pull requests | ## 2. Immutable action references Every `uses:` was a mutable tag. Pinned all six to full commit SHAs with the version in a trailing comment, matching what the two in-repo composite actions already get from SHA-locked submodules. Dependabot keeps updating SHA-pinned actions, so this does not freeze them. ``` actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 actions/setup-java@1bcf9fb12cf4aa7d266a90ae39939e61372fe520 # v5.4.0 actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6 actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7 actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5 peter-evans/create-pull-request@5f6978faf089d4d20b00c7766989d076bb2fc7f1 # v8.1.1 ``` Worth noting: `actions/dependency-review-action@v5` was not a tag at all — `v5` is a **branch** on that repository, which is looser still than a tag. ## 3. Deploy credential scope `NEXUS_DEPLOY_USERNAME` / `NEXUS_DEPLOY_PASSWORD` were job-level `env:` in `asf-snapshots-deploy.yml`, so they were in the environment of every step in the job, including `checkout` and `setup-java`. Moved onto the deploy step, which is the only one that needs them. ## 4. Build toolchain integrity `.mvn/wrapper/maven-wrapper.properties` pinned `distributionUrl` but had no `distributionSha256Sum`, so `mvnw` skipped verification — `Cannot checksum, no distributionSha256Sum set` — on every build path: all workflows, the Jenkinsfiles, and `release-utils/release.sh`. `repo.maven.apache.org` publishes only a `.sha512` for this artifact, so I verified the distribution against that published SHA-512 first and derived the SHA-256 from the same verified bytes: ``` published sha512: 8beac8d1...4c4418ba local sha512: 8beac8d1...4c4418ba MATCHES derived sha256: 4ec3f26fb1a692473aea0235c300bd20f0f9fe741947c82c1234cefd76ac3a3c ``` Confirmed it is enforced fail-closed, by pointing a fresh `MAVEN_USER_HOME` at a deliberately wrong value: ``` Error: Failed to validate Maven distribution SHA-256, your Maven distribution might be compromised. ``` and confirmed a clean download against the real value succeeds. ## Also `scm/connection` in `pom.xml` used `http://`; `developerConnection` on the next line already used `https://`. ## Verification - All eight workflow files parse as YAML with the intended `permissions` values. - Full reactor build from the repository root (`./mvnw clean install -DskipTests`): BUILD SUCCESS. ## Not included `backport.yml` resolves `./.github/actions/backport` from the pull request's merge commit. Since the trigger is `pull_request` (not `pull_request_target`), a fork PR gets a read-only token and no secrets, so the exposure is limited — and changing it means restructuring how that action is resolved. Left out of this PR deliberately; happy to follow up if you want it. -- 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]
