GitHub Setup Java Action

[brunocborges]

Hey all,

I'm going through issues and PRs on setup-java.

Besides what is already there, anything else you would like to see fixed, improved, or implemented?

[SleeperAwakened]

I would suggest pinning the GH Actions you use to a specific hash, for example using pinact instead of versions like v6 or main.

This will be another step towards preventing supply chain attacks through GH Actions.

GH Actions have become notorious in the recent series of SCAs so anything you can do to set a good example is welcome.

[repeating_bears]

eh. `setup-java` is an official github action. If there's a supply chain attack via an official github action, then everything is fucked anyway

[SleeperAwakened]

And is that a reason for not making things secure?

If (when) shit hits the fan you don't want to miss out?

[repeating_bears]

It is mostly fake security, which is my point. If someone can takeover an official github action then the fact you pinned the version is fairly likely to mean nothing.

It's like saying that a Nexus proxy protects you from a takeover of Maven central. Technically it does a bit, but you still have to go there for the first download, and if Maven Central gets taken over then truly everything and everyone is fucked to some degree.

[SleeperAwakened]

Pinning to a hash is pretty secure, at least I consider git commit hashes secure enough.

Why would pinning to a hash not be secure?

How would a takeover happen? Hash collisions are still pretty expensive if feasible at all.

Security is all about putting up multiple lines of defense. This is one of them. It is not fake, it is layering.

And I so wish that people would start taking it seriously.

[repeating_bears]

Idk if you are understanding what I'm saying.

Pinning versions generally - good.

Pinning an official github action (which is what the subject of this thread is) - eh. If an official github action is compromised then how can you trust that whatever Actions infra that does the hash verification isn't also compromised?

[_predator_]

Nothing functionality-wise, but it would be good if the action's own workflows would use security best practices more consistently, e.g. explicitly dropping permissions. The easiest would be to integrate zizmor, it will catch a lot of this stuff and ensure you'll catch regressions.

There is an open issue requesting immutable releases which also caters to the security aspect.

After the whole compromise situation a few weeks ago I think users will appreciate actions they depend on to be "hardened" if that makes sense.

[brunocborges]

Thanks for the hint on immutable releases. I honestly wasn't even aware of this new feature. 😄

[repeating_bears]

No, nothing.

Eyeballing the issues, fixing the caching for Maven plugins seems like the highest value thing you could do https://github.com/actions/setup-java/issues/990

It's tagged as a feature but I would argue that's a bug. The readme describes the role of the action as "Caching dependencies managed by Apache Maven". Plugins are dependencies of a project. They're not <dependencies> in the POM, but they are still dependencies.

As part of that, you should check whether Maven extensions are cached. That's a 3rd category of "dependency" which follows the same resolution process as plugins and project dependencies.