Tighten security of Actions workflows #5930
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was recently reading an article about a repository whose release workflow was compromised due to code injection and how it could have been detected using zizmor. I did some auditing here of the Actions workflows, both manually and with zizmor, and I didn't find any obvious security problems, but I did some hardening.
The first patch was from my manual auditing and covers some improved shell quoting. This isn't currently exploitable, but we might as well avoid the problem altogether and using proper shell quoting is a best practice anyway. The second patch comes from the recommendation of zizmor.
We are following the best practice of storing expanded Actions patterns (those with
${{}}) in an environment variable before using them, because this prevents injections (such as from refs containing shell characters). Actions doesn't have any sort of quoting for these cases, but by passing them in via the environment, we can use the normal shell quoting rules for these purposes.So overall, I think we're in a good spot, but this PR just makes it a little less inviting as a target.
This PR contains independent, logical, bisectable commits each with their own commit message, and as such is best reviewed commit by commit.