[hashcatHitman]

In pursuit of getting more zizmor lints enforced across rust-lang repos through crabwatch, this PR fixes all findings of the concurrency-limits, ref-version-mismatch, stale-action-refs, superfluous-actions, and unpinned-uses rules (there were no findings for unpinned-uses in this repo, though) (this leads to resolving all possible findings with zizmor 1.31.1).

For actions/checkout, it seems 6.0.2 may have been re-tagged at some point. You can compare the old commit and the new commit here: https://github.com/actions/checkout/compare/de0fac2e4500dabe0009e67214ff5f5447ce83dd..0c366fd6a839edf440554fa01a7085ccba70ac98

The only difference is changelog entries being added.

For dtolnay/rust-toolchain, it seems like re-tagging is the only tagging it knows. Fortunately, rustup is already installed on ubuntu-latest, windows-latest, and macos-latest. Switching to using rustup directly clears ref-version-mismatch and stale-action-refs, with the added benefit of clearing superfluous-actions.

The hash pin format is supported by tools like Dependabot and Renovate, which can update the pinned hashes and their associated comments. If you'd like help setting either of those up, let me know which you prefer, and if you'd like it in this PR or a new one.

[Thomasdezeeuw]

Why can't we use dtolnay/rust-toolchain?

View changes since the review

[hashcatHitman]

1. It doesn't really offer much over using rustup directly, especially for very simple toolchain needs like we have here. So using this action instead of the pre-installed rustup does extra work and increases our attack surface/supply chain risk. Even if dtolnay already has write access to this repo (I don't know if they do or not), depending on this action when we don't need to is just a possible path to compromise in the future when they might not have write access anymore. (which, to be clear, I am not suggesting I think dtolnay is going to try to do anything. I am suggesting if dtolnay were to have their account or credentials compromised, the attackers could then act on their behalf)
2. It doesn't have proper releases/tags. The only release/tag is v1, and the tag just gets moved around to new commits, making it impossible to properly satisfy ref-version-mismatch and stale-action-refs. We could tell zizmor/crabwatch to ignore those lints, but because there's no proper version comment that would match the hash consistently, Dependabot can't keep this action updated. An alternative would be to track the literal tag v1 or the master branch itself, which should remove the need to update the action to get additional fixes, but that leads to unpinned-uses failing, which is also not desirable. Similarly, we could configure zizmor/crabwatch to ignore that as well, but unless there's a concrete reason to prefer the action over using rustup directly, it's just better for our security posture to do away with it.

Ultimately, my goal is just to get the lints to pass so we can enable them and improve our security posture across the rust-lang repos. It is preferable to replace the action with rustup directly, but if you have a reason to prefer the action, there are other ways I can satisfy the lints. If you do have a reason and want to keep using the action, I'd need to know if you'd rather stick on a commit, which puts you at risk of falling far behind on updates, or if you'd rather track the tag/branch directly, which leads to less stability and slightly increased supply chain risk over using a commit or rustup directly.

[KodrAus]

There's a v7 of checkout now I think so while we're updating it we may as well use that, unless you're specifically trying to align everything to the same version

View changes since the review

[hashcatHitman]

I'm specifically trying to avoid updating things unless asked. The v6.0.2 tag does not point to the old commit, it points to the new one. It doesn't look like any tag points to the old commit, and there's no real code changes between the two (see the comparison link in the PR body).

But yeah, I'll update this to v7 for you, that's not a problem at all.

[KodrAus]

@hashcatHitman I'm not familiar with zizmor or crabwatch myself. It looks like we have a workflow somewhere auditing the workflows of other repos? What's the overall plan here? Is this the first of a series of changes to how rust-lang projects do CI and should we expect more later? It would be good to have some idea of what the end state we're aiming for is so we're not looking at each change in a piecemeal way.

[hashcatHitman]

@hashcatHitman I'm not familiar with zizmor or crabwatch myself.

zizmor is a static analysis tool meant to help secure GitHub Actions Workflows. I like it a lot, personally. The full list of lints and their justifications/explanations is available here: https://docs.zizmor.sh/audits/

crabwatch is an effort by t-infra to audit CI across the entire rust-lang organization. It uses zizmor under the hood, but I believe custom lints may be added in the future.

It looks like we have a workflow somewhere auditing the workflows of other repos?

Yes, that's crabwatch. I believe it was first announced here: #t-infra/announcements > GitHub Actions linter

What's the overall plan here? Is this the first of a series of changes to how rust-lang projects do CI and should we expect more later? It would be good to have some idea of what the end state we're aiming for is so we're not looking at each change in a piecemeal way.

I'm not a member of t-infra, so take what I say with a grain of salt. Currently, crabwatch only runs a subset of the lints included with zizmor. t-infra is working on increasing the number of lints that are enabled gradually. To avoid breaking workflows, the plan is usually to go out and fix the lints first, then enable them. Repositories can help out by resolving lints and opting themselves in early. I asked if other people could help too, and t-infra had no issues with it (See: #t-infra > questions about helping with crabwatch/zizmor). So I'm picking out a few of the lints to try to resolve at a time. You're free to reject or push back on any of my changes if you don't want them, but I think, generally speaking, we would like to enable most of these lints and create exemptions only when needed (which can be done, by the way, so if something you need is causing a lint to fire, it can just be ignored with an inline comment).

If you want to avoid the noise of multiple visits, I can also resolve more findings in this PR if you want (I've just started trying that approach elsewhere). But that will come with more of the "questionable-to-no-real-benefit" lints (which very well may never be enabled organization-wide).

[hashcatHitman]

If you want to avoid the noise of multiple visits, I can also resolve more findings in this PR if you want (I've just started trying that approach elsewhere). But that will come with more of the "questionable-to-no-real-benefit" lints (which very well may never be enabled organization-wide).

Actually, now that I check, the only other lint that fires for this repository is concurrency-limits, which I can pretty easily fix, so I'll just throw that in now.

[Thomasdezeeuw]

I think the toolchain action is easier to work with than the shell commands, but I'm fine with removing it.

View changes since this review

[KodrAus]

Thanks for helping out with this @hashcatHitman!

Standardising our CI workflows across the org does seem like a good idea. I guess we need to move to trusted publishing at some point too. I currently publish releases of log through my own infra so when we make that change I’ll disable mine.

View changes since this review

[hashcatHitman]

I guess we need to move to trusted publishing at some point too. I currently publish releases of log through my own infra so when we make that change I’ll disable mine.

I think @Kobzol has been going around switching a lot of our crates to trusted publishing lately, so you might get a visit from him soon about that.

[Kobzol]

I'm happy to set that up, though it requires some input from maintainers. I'll discuss it with KodrAus.

Edit: opened #743