enable dependabot for github actions

[danmoseley]

This will make a few PR's like

danmoseley#12
danmoseley#13

and we can decide whether to take them. I think in general we would (eg., some old versions are getting deprecated)

@jeffhandley we discussed whether actions need to have hashes to securely identify their implementation. That is unrelated to this change (well, except they might need updating as well), but I can't find your answer. Would you mind answering that again?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

For using full-length SHAs instead of tags, that approach was based on the Security hardening for GitHub Actions - GitHub Docs.

• Pin actions to a full length commit SHA

Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.

• Audit the source code of the action

Ensure that the action is handling the content of your repository and secrets as expected. For example, check that secrets are not sent to unintended hosts, or are not inadvertently logged.

• Pin actions to a tag only if you trust the creator

Although pinning to a commit SHA is the most secure option, specifying a tag is more convenient and is widely used. If you’d like to specify a tag, then be sure that you trust the action's creators. The ‘Verified creator’ badge on GitHub Marketplace is a useful signal, as it indicates that the action was written by a team whose identity has been verified by GitHub. Note that there is risk to this approach even if you trust the author, because a tag can be moved or deleted if a bad actor gains access to the repository storing the action.

It's interesting though that dependabot doesn't lead us to follow that guidance, and it instead relies on tags. I'm conflicted on this.

[jeffhandley]

I wonder if we should use a different area label for repository automation, separating that from "infrastructure", perhaps creating area-github-automation?

[jeffhandley]

Yeah, area-codeflow is OK with me.

[danmoseley]

Thanks for the info.

For hashes -- since we don't have hashes today, I suggest to take this change as it's a step forward - if there's a security fix we'll now get that - and solve hashes separately. (I suppose concievably that could mean disabling dependabot, if it doesn't know how to update hashes, idk)

Actually -- SHA-1 (!!) wasn't that broken 20 years ago? Would this provide any actual security? @GrabYourPitchforks

[danmoseley]

As for labels - what about using area-codeflow ? that's what it is. It's incidental that it's dependabot

[jeffhandley]

Actually -- SHA-1 (!!) wasn't that broken 20 years ago? Would this provide any actual security?

Nodding along. The doc references this too with, "they would need to generate a SHA-1 collision for a valid Git object payload." So it's not unbeatable; just harder to achieve than retargeting a tag. To this point we either trust the repository or we don't, and the latter part of the guidance addresses this as:

Although pinning to a commit SHA is the most secure option, specifying a tag is more convenient and is widely used. If you’d like to specify a tag, then be sure that you trust the action's creators.

Consider me convinced that shifting from SHAs to tags is OK. We need to follow due diligence to vet the repositories we reuse actions from regardless, and we have been.

[danmoseley]

Feedback addressed

[martincostello]

@danmoseley You should be able to use SHAs with dependabot - I do exactly that in my OSS repos. Dependabot will update you from one tag to the next when there's a new release, but keep it referenced as a SHA. If you reference a SHA that isn't a tag, then it'll keep ingesting updated tags as the branch associated with that SHA moves along.

For example: martincostello/update-dotnet-sdk#844

[danmoseley]

Thanks. Any thoughts any whether the security here is illusory? I guess it raises the bar a little.

[martincostello]

I think the main concern is people swapping the tags from under you in the original repository at a later point after you start using it (kinda like a "long con" as you need the original user to merge/run the action first and be happy it seems to do what was expected).

For example I could make a tag called v1 and you use it and everything's fine and dandy, and then at a later point I make a "hacker" branch with a version that tries to steal all the repo secrets that's completely different to how you were using the action originally when it was reviewed/audited and re-target my v1 tag to that commit, then the action will run at some point and then execute the malicious version instead of what was originally intended.

I think how "tin foil hat" that level of paranoia goes depends on who you are using actions from (I would hope the GitHub actions org be "trusted" as-is, for example) and what the risk/impact of what could be stolen/whatever by any malicious action that runs in the context of your GitHub Actions runners' execution context.

I think the more useful use case for the SHAs is stability, rather than security. If there's a bad patch release of an action that breaks something (e.g. v1.1.0 has a bug and I'm using v1), then I'll be exposed to that bug as soon as the new action version gets published until it's fixed, where as if I pin by SHA, I stay on the "good" version indefinitely. Dependabot will then update it later, and the PR would break (assuming it's a CI-related action, not a process action like stale tagging) and I know not to take the broken change.

I guess the TL;DR is: tags mean less updates but more risk of potential breakage as the action releases new versions and a separate risk that the tags could be repointed to be malicious, but SHA is more churn to keep up-to-date but with the benefit of stability and an unlikely ability to inject arbitrary code (unless somehow the bad actor could manufacture a SHA-1 collision on the Git commit with their malicious payload)

[danmoseley]

If there's a bad patch release of an action that breaks something (e.g. v1.1.0 has a bug and I'm using v1), then I'll be exposed to that bug as soon as the new action version gets published until it's fixed, where as if I pin by SHA, I stay on the "good" version indefinitely.

I'm missing this -- v1.1 would be picked up automatically somehow, without Dependabot?

(unless somehow the bad actor could manufacture a SHA-1 collision on the Git commit with their malicious payload)

Right, SHA-1 is broken, that's why I was wondering whether there's any meaningful value over a version number.

[danmoseley]

ofc, since you've shown Dependabot is happy to update SHA's, there's no downside as far as I see.

[martincostello]

I'm missing this -- v1.1 would be picked up automatically somehow, without Dependabot?

To take my own action repo as an example (which follows the practice the actions actions follow, so I assume it's best practice) when I do a new release, I create it with a vX.Y.Z tag, and then I have some automation that re-points my vX tag to point from the previous latest release to the newly released tag (effectively what the attack is in principle, except not malicious 😄).

So today v3 points to v3.2.1, but last week it pointed to v3.2.0. If I point to v3 in a repo, then I get upgrades within a minor major version "for free" without dependabot's involvement, I would only need it to move to v4. If I used the v3.2.0 tag then I wouldn't get an upgrade and need dependabot to move to v3.2.1.

Right, SHA-1 is broken, that's why I was wondering whether there's any meaningful value over a version number.

For me it's stability, seeing the changelog as dependabot raises PRs etc., rather than stuff just changing under me with no visibility. I think the SHA-1 broken-ness is probably for the average user quite a low possibility and is more to most intents theoretical.

[danmoseley]

A gotcha - I hadn't absorbed these were tags and not release versions. Yes, this does seem worth doing.

I think we can merge this as is and follow up on that after.