Turn on immutable GitHub releases for this project

[connorshea]

Hello! Given the recent attacks on GitHub Actions where credentials were compromised and then tags got overwritten (e.g. this one from today), it would be a good idea to turn on immutable releases for the Git tags in this repo to prevent that kind of attack from hitting this repo: https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases

This wouldn't fix the problem entirely and would not protect someone using ruby/setup-ruby@v1 if an attacker published a new, malicious v1.x release, but it'd at least help protect some users in some cases for minimal work (e.g. if they had ruby/setup-ruby@v1.310.0 and that tag was immutable, they'd be safe).

Unfortunately you can't turn on immutable releases retroactively without un-publishing and re-publishing existing releases, but we can at least ensure that all future releases are immutable 🤷‍♂️

[ntkme]

As you already mentioned, immutable releases do not solve much of the security problem when write access is leaked.

As for end users who have concerns over immutability of changes, our recommendation is always to lock the github actions at specific git commit sha, instead of git branch or tag. For example:

https://github.com/ruby/rubygems/blob/7a326f540448ca3cfd7a6a897c29403a2b8b2417/.github/workflows/rubygems.yml#L60

Note:

1. Dependabot supports updating git commit sha for actions, so you can still get updates this way as usual.
2. sha256 collision attack is theoretically possible, but realistically not possible anytime soon.

[hakusaro]

As you already mentioned, immutable releases do not solve much of the security problem when write access is leaked.

It does, because if write access is leaked you still cannot republish an existing tag.

[ntkme]

This wouldn't fix the problem entirely and would not protect someone using ruby/setup-ruby@v1 if an attacker published a new, malicious v1.x release

You can read the security recommendations from GitHub: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions

They also recommended “pin actions to a full-length commit SHA” as a stronger security measure than “pin actions to a tag.” Whether a tag is immutable or not is irrelevant when pinning by SHA.

You may also want to read discussions in regarding this topic, that the scope of immutable releases for this project is way larger than you would think as this project use binaries from multiple other repositories: #848