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

[eregon]

Using immutable releases for ruby/setup-ruby releases itself would probably be easy, but indeed it doesn't achieve much.

https://github.com/ruby/ruby-builder is where immutable releases would matter, but then that gets in the way of legitimately rebuilding a release (rare to be fair, but it has happened that a build succeeded yet the Ruby was broken so we had to rebuild it, compilation is not always deterministic) and adding new platforms when they become available. It's in theory possible to find ways around that but it sounds very complicated and inconvenient.

If someone gets write access though, can't they publish new immutable releases (of either repository)?
If so, what have we gained security-wise?

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

This is already prevented, tags are immutable for this repository, i.e. they can't be updated, deleted or force-pushed by anyone, via a Ruleset.

[ntkme]

https://github.com/ruby/ruby-builder is where immutable releases would matter

In addition, we have these dependencies where immutable releases would matter for ruby on windows:

• https://github.com/ruby/setup-msys2-gcc
• https://github.com/oneclick/rubyinstaller2

setup-msys2-gcc would be the most challenging one to achieve true immutability, as right now we check for update every day and it publishes new releases a few times every week. setup-ruby always consumes the latest release of setup-msys2-gcc. It means that if we want to achieve immutability, we would have to switch to specific release tags, and create a new release for setup-ruby every time we update setup-msys2-gcc. It would be extremely noisy to the end users with hundreds of immutable releases per year.

Turning on immutable releases is one thing, how to effectively use immutable releases is another thing - we can easily enable immutable releases for setup-msys2-gcc, but as long as setup-ruby continue to use latest, it does not make anything better in terms of security as hacker may just publish a new latest compromised immutable release.

[hakusaro]

This is already prevented, tags are immutable for this repository, i.e. they can't be updated, deleted or force-pushed by anyone, via a Ruleset.

If a contributor with the ability to change rules is compromised, changing the ruleset is trivial.

[eregon]

If a contributor with the ability to change rules is compromised, changing the ruleset is trivial.

In such a case (which requires admin access AFAIK), isn't it also trivial to disable immutable releases?
Existing releases would still be immutable, but new releases wouldn't be.

I think the bottom line is if an attacker gains write access, they could make a new release (whether immutable or not) and that's not helped by immutable releases, isn't it?