Hash-pin GitHub Actions

[pnacht]

Summary of changes

Closes #4025.

This PR hash-pins all GitHub Actions used in workflows to protect the project from supply-chain attacks. It also configures dependabot to keep the Actions up-to-date.

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[abravalheri]

Thank you very much for the contribution Pedro. I will leave this one for @jaraco to judge.

Although, I have to say even with dependabot, this sounds very inconvenient 😅.
You mentioned in the issue "malicious attacker". The malicious attacker would have to be a maintainer of the specific action (or a person that has admin access, e.g. a Github employee), right?
In that sense, it does not look different to me from any other runtime/build-time dependency... Does it mean that we will have to start pinning everything from now on?

Maybe a better approach would be for the next link of the dependency chain to pin setuptools instead...

[pnacht]

Hey @abravalheri, thanks for the quick reply!

So, this is just about hardening your CI/CD. Since your workflows already run with minimal permissions (the permissions.contents: read block at the top of the workflows), the main risk from a malicious Action would be leaking credentials or poisoned releases.

main.yml's release job seems to publish to PyPi. If one of the Actions became malicious, it could poison your environment and cause the wheel/dist to contain malicious behavior not found in the actual source code. Alternatively, they could simply steal your PyPi token and push their own malicious version.

I can't quite understand what ci-sage.yml does, but it seems to push a docker image which consumes an artifact created by your workflow. I suspect this is just for testing purposes, but if this docker image is actually sensitive, the Actions could also be used to poison that image.

---

But yes, this does add some overhead. setuptools currently has the following Actions:

• actions/checkout (new release every ~2 months)
• actions/upload-artifact (every ~5 months)
• actions/setup-python (~1 month)
• actions/cache (~1 month)
• codecov/codecov-action ( ~6 months)
• re-actors/alls-green (hasn't been updated since October 2022, but used to be updated every ~2 months... honestly looks abandoned now...)
• cygwin/cygwin-install-action (~6 months)

So this would likely average to something like 1 dependabot PR every 1-2 weeks.

[webknjaz]

• re-actors/alls-green (hasn't been updated since October 2022, but used to be updated every ~2 months... honestly looks abandoned now...)

Not abandoned but feature-complete.

[webknjaz]

weekly is going to be quite noisy

[webknjaz]

Pretty sure this is not going to be compatible with the current mass-maintenance workflow because it will be actively introducing merge conflicts all the time: #4025 (comment).

[jaraco]

As proposed, this change is untenable, as it happens per-repo and increases the per-repo maintenance burden substantially. As webknjaz has described, this project is maintained alongside the hundreds of other projects I maintain, many of which are derived from jaraco/skeleton. Before we embark on recommending the change there, I'd like to take a step back and understand better what's being proposed (why it's beneficial).