[ci][gh][workflow] explicit action hash and permissions

[rmannibucau]

Trying to harness more our workflows - but maven shared is designed to be too opened.
Audit mainly done by zizmor.

[gnodet]

Clean security-hardening PR that adds top-level permissions: {} and explicit job-level permissions to three workflow files, pins reusable workflow references to a verified commit hash, and adds a justified zizmor annotation. All changes are correct and consistent with the already-hardened maven.yml workflow.

Verified that:

• The commit hash 8599b638c78a2bec146a98d75d4c8b4e8458324f matches the current HEAD of the v5 branch of apache/maven-gh-actions-shared
• Job-level permissions in all three workflows match what the corresponding reusable workflows require
• The zizmor: ignore[dangerous-triggers] annotation on the pull_request_target trigger in pr-automation.yml is appropriate since the workflow only triggers on closed events
• All four workflow files in the repository are now hardened

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

[slawekjaranowski]

It is intensionally here.

We assume our repo with shared actions is secure, we introduce every changes to it.

When we pin to hash we need update about 100+ our repos in every changes in shared actions.

We also manage permissions in shared action.
https://github.com/apache/maven-gh-actions-shared/blob/v5/.github/workflows/pr-automation.yml

[rmannibucau]

I understand but I dont think we should auto upgrade all repos like that, this is a good idea today which will likely blow up tomorrow so better to invest in automating it with a workflow in shared repo (on demand/manual) than relying on it by default IMHO

permissions being per workflow/job it is always better to explicit it in leaves than in parents IMHO, in particular when there it does have some serious impact on the run of the workflow (not having write perms will fail and you can wonder why - would be ok only if read only for PR IMHO)

[slawekjaranowski]

for permissions I'm ok,

but for hash version I afraid that will be more maintenance work for us - who will be take care about it?

[rmannibucau]

what I had in mind was something like dependabot and we do approve after review as any "jar" dependency, wdyt?

[gnodet]

Permissions hardening looks correct — the permissions: {} top-level lockdown plus job-level grants across all three workflow files follow least-privilege and are consistent with how maven.yml already operates.

Stale pinned hash — the pinned hash 8599b638c78a2bec146a98d75d4c8b4e8458324f (July 20) is now 7 commits behind the current v5 HEAD (07649a12f6dacdb747f586cdd6f5cb52b1993eff). The missing commits include bumps to release-drafter 7.7.0, actions/stale 11.0.0, actions/setup-java 5.7.0, Maven 4 RC-6 default, a verify-job startup fix, and a timeout-lowering change. If hash pinning is kept, the hash should be updated before merge.

The broader policy question — whether to hash-pin org-internal shared workflow references (security hardening vs. maintenance overhead across 100+ repos) — remains open between the author and maintainers. Dependabot does support updating hash-pinned references (using the trailing # v5 comment), which mitigates some of the maintenance burden.

Minor: the 3-space → 2-space indentation fix in release-drafter.yml and the zizmor: ignore[dangerous-triggers] annotation (justified since pull_request_target only triggers on closed) are both correct.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet