Proposals for being able to pin setup-ruby action?

[chadlwilson]

The current recommendation for setup-ruby is to use a mutable tag, since new ruby versions (even patch releases) are only available via a code change.

Two GitHub actions breaches in the space of a month have brought renewed attention to the additional risks of (some) unpinned actions. https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise (TL:DR trivy itself was compromised allowing a writeable GITHUB_TOKEN to be stolen, later breach allowed malicious corrupt trivy-action mutable tags to be published that stole secrets from every actions run of users pointing to a mutable tag - investigations still under way though)

The challenge (and risk associated with) this setup-ruby action appears to stem from conflating data (available binaries for install) with code (how to setup a given ruby).

Have maintainers given any thought to ways to decouple this which would still be maintainable, sufficiently automated to reduce maintenance burden - but mitigate some of these challenges in a way that'd allow pinning the action while still having new rubies become available?

If not, would you be open to proposals to do so, if something is possible without being security theatre? (I am not familiar with the source, but interested to explore if maintainers are open to ideas to address, even if it results in no change and perhaps just some documentation of ways for users to mitigate risk or even why this action may be less vulnerable than others).

[ntkme]

1. Leaking write access is a game over no matter what. Limiting token access scope, limiting who has access, and making sure people who have access are responsible, are more important than anything else.
2. For users who want highest level of security, they should use locked down git commit reference in their workflow instead of mutable tag. If you need updates, use dependabot to update the commit sha, and you can review each change. For example: https://github.com/ruby/rubygems/blob/edbc8d075ca82bd383968918c9fee3954feed19a/.github/workflows/rubygems.yml#L54
3. The variable “v1” branch reference is a choice over convenience of receiving automated updates instead of have fully immutable and reproducible builds. You cannot have them at the same time.
4. Decoupling ruby versions update from the action update does not avoid security issue at all, instead it just move the issue to somewhere else, meaning that we have two places for potential supply chain attack instead of one.

[chadlwilson]

1. Leaking write access is a game over no matter what. Limiting token access scope, limiting who has access, and making sure people who have access are responsible, are more important than anything else.

Yes, I agree, which is why I am suggesting finding ways to improve and limit the access further. The scope of a potential leak and the speed at which any compromised changes reach users makes a difference so "game over" isn't actually so binary.

Users are currently faced with a trade-off which could possibly be less harsh than it current is. (pin actions shas to improve github actions security posture --> either increases maintenance burden of managing dependabot updates/PRs OR delays speed of being able to use/get ruby patch releases which may have security implications themselves)

2. For users who want highest level of security, they should use locked down git commit reference in their workflow instead of mutable tag. If you need updates, use dependabot to update the commit sha, and you can review each change. For example: https://github.com/ruby/rubygems/blob/edbc8d075ca82bd383968918c9fee3954feed19a/.github/workflows/rubygems.yml#L54

Yes, I understand this pattern (that's why I am suggesting it); however it is not the case with other such setup- actions that such sha-pinning prevents you getting new underlying runtime releases; so there is the trade-off in the canonical setup-ruby action in terms of maintenance overhead or 'slowdown receiving patches' (not present in most other ecosystems).

My contention, which I'd explore further if a proposal was welcomed, that there are likely approaches that are much less "binary" in nature and would make the trade-offs less harsh.

3. The variable “v1” branch reference is a choice over convenience of receiving automated updates instead of have fully immutable and reproducible builds. You cannot have them at the same time.

I understand the motivations; however the current docs also strongly recommend it to users; without noting that this is against most good security practices - which is why I also specifically suggested improving the documentation (which I am happy to submit a PR for) even if you decide not to change anything.

4. Decoupling ruby versions update from the action update does not avoid security issue at all, instead it just move the issue to somewhere else, meaning that we have two places for potential supply chain attack instead of one.

I feel you are getting ahead of things. I am asking whether you/others are open to a proposal/argument; but I have not actually made any proposal that can be evaluated for its trade-offs. This seems to pre-suppose that no such possibility of improvement exists.

I am asking here because it is unwise to spend time if it is already been evaluated; or if maintainers have already concluded/discussed that there is no such possible improvement that you'd accept.

[dentarg]

I am asking here because it is unwise to spend time if it is already been evaluated; or if maintainers have already concluded/discussed that there is no such possible improvement that you'd accept.

(I'm not a maintainer but I've been following setup-ruby since its inception)

I would imagine it is hard to say what would be accepted (or not) without seeing an actual proposal? I think the discussion that took place in #848 is of somewhat relevance, if you haven't seen it.

[chadlwilson]

I didn't ask whether a proposal would be accepted, (nor an implementation thereof). I'm merely asking whether people see there might be opportunities for improvement sufficient to consider proposals and engage in a discussion.

Submitting a lengthier proposal is also requesting effort and is an imposition of a sort - my philosophy is that there's no harm asking for permission first. I do not know the pressure the maintainers are under, nor their focus areas. Perhaps they have much bigger problems to solve.

I'm not even saying I'd have the capability to implement any proposal/design solely myself, but if the team don't have the energy to discuss the merits and have other priorities then it'd be better for me to spend time elsewhere.

And yes I've seen that thread. I had some ideas there too, but deliberately chose not to interject since I am an outsider.

[eregon]

Feel free to make a proposal, as a discussion.
For my side for it to succeed it would have to require little work from me.