Hash-pin all action usage, address other minor CI security considerations

[woodruffw]

Hello! Apologies for the cold PR.

I'm opening this in my capacity as one of uv's maintainers; we have a set of downstreams (including http!) that we depend on, and we'd like to ensure their CI/CD processes are as hermetic and secure as possible (within the limits of GitHub's platform).

To that effect, this PR contains a few different commits that aim to make http's CI more secure. None of these changes fix vulnerabilities; they're purely defense-in-depth changes that will make a future Trivy-style compromise less fruitful for an attacker.

To summarize:

• I've hash-pinned all of your action dependencies with pinact run -v. These can be kept up-to-date with pinact locally or by adding Dependabot to your repository (for Github Actions only, potentially), but I've left that out to keep the size of this PR down.
• I've disabled actions/checkout's default credential-persistence behavior with persist-credentials: false, where possible.
• I've dropped your default permissions to {}, since you don't actually use any other permissions.

Most of the above was detected automatically with zizmor, which you can integrate into GitHub Actions if you'd like. I've left that out of this PR however, since not every project wants another thing running in CI. But let me know if you'd like it and I'd be happy to send a follow-up PR!

Last but not least, please let me know if there's any other information I can provide. All of the above was 100% human written and reviewed 🙂

[seanmonstar]

Thanks for the PR!

Hm, these actions don't have write access to anything. So any malicious actor wouldn't be able to commit anything. Right?

And the downside here is that we would then need to manually upgrade these actions (even if using a bot), making noise in the PRs and commits.

[woodruffw]

Hm, these actions don't have write access to anything. So any malicious actor wouldn't be able to commit anything. Right?

Yep, 100% correct. In your case I'd say the risk is exceedingly small 🙂

(The nuance with Github Actions is that even with no permissions each job gets a branch-scoped cache token, so a compromised action may be able to poison caches starting at the "top" of the branch tree i.e. main. In your case there's not much an attacker could do with that since you're not doing anything sensitive in CI, but it's worth keeping in mind should you ever decide to publish from CI or similar.)

And the downside here is that we would then need to manually upgrade these actions (even if using a bot), making noise in the PRs and commits.

Yeah, this is unfortunately true. I'm hoping GitHub comes up with a better locking story for Github Actions soon, but for the time being we get these pretty noisy diffs instead. Personally I think it's worth it (in terms of hermeticity), but each project is different and as you note you have very little exposure here.

If you're going to find that troublesome, I'm happy to revert the hash-pinning bits (or close the PR entirely if you don't want the permission bits either).

[seanmonstar]

Thanks for the write up, and for bearing with me. I think in our case, the benefits do not outweigh the costs. I appreciate the thought and care you put into it, though!

[woodruffw]

No problem, thank you for the considerate review! And for maintaining so much of Rust's HTTP stack 🙂