Address zizmor findings:

[cpovirk]

• persist-credentials: false
• pinning uses

There may be other findings, but these are the easy ones.

[cpovirk]

JDK 23 CI has been failing since #5979. Separate from this PR, I'm going to fix the failure and fix the misconfiguration that allowed Copybara to merge PRs that were failing that one particular check.

[cpovirk]

Now actually passing the zizmor (GitHub Actions Scan) check.

I have gotten myself mixed up a few times with zizmor, and I'm not entirely sure whether it's actually misbehaving in some cases, whether I'm holding it wrong, or whether I've just been mistaken about things as I juggle changes to various repos.

One place where I have just been mistaken is that I've assume that zizmor is blocking internal submits via the Copybara presubmit. That's not true, since Copybara waits only for CI tasks that it's explicitly configured to wait for (as seen recently in our discussions about JDK 23). I also have come to suspect that it's not blocking even merges in GitHub, since I don't see Branch Protection rules that request that, even though it shows up as a failing check. (I don't know what Branch Protection rules Error Prone has in place at the moment, anyway.) But I don't have a handy PR available to check that on, and I'm not invested enough to create one.

All that is separate from the question of whether we might want zizmor failures to block changes, such as if someone sends us a PR to allegedly update some GitHub Actions action to a new release but that actually points to something evil. zizmor might catch cases in which the comment is wrong (though I haven't verified that to 100% confidence, either).

One thing I note on this specific PR is that it seems a bit strange for zizmor to insert comments of the form"v7,", since I wonder if that tag might get force-pushed to the latest v7.x release periodically? But I'm happy to move in the general correct direction and to satisfy zizmor today. We can always do more in the future.

(IIRC, we merge changes to .github directly in GitHub, since we don't have those files in our internal repo? I would do it myself for this + google/turbine#466 + google/google-java-format#1431 (and for #5988 once we have a direction set there), but I don't have permissions.)

[cushon]

Thanks!

IIRC, we merge changes to .github directly in GitHub, since we don't have those files in our internal repo?

Yes these files are extenal SoT and aren't synced, to make it easier to iterate on CI config changes.

I can merge this one and #1431, are they ready to go?

[cpovirk]

Thanks, yes, they should be good, along with the Turbine one that you may have had reasons for not mentioning yet.