chore(ci): address lint findings in release workflow

[woodruffw]

Summary

This should be the last of the main linting changes; with this, there will be no more non-pedantic zizmor findings.

Test Plan

See what happens in CI. I'll also and manually dispatch a dry-run.

[woodruffw]

Oh hm. I guess I need to update cargo-dist itself for this?

[zanieb]

cc @Gankra

[konstin]

iirc those are actually used, we're pushing a tag and creating a release

[woodruffw]

iirc those are actually used, we're pushing a tag and creating a release

Oh hmm, I thought each job had its permissions explicitly set already but I see I missed announce. I'll fix this.

[konstin]

The cargo-dist workflow is generated from https://github.com/astral-sh/cargo-dist/blob/622170f09a1521bc0782332317076e4805737cef/cargo-dist/templates/ci/github/release.yml.j2, where we can update it.

[woodruffw]

The cargo-dist workflow is generated from astral-sh/cargo-dist@622170f/cargo-dist/templates/ci/github/release.yml.j2, where we can update it.

Ah, this looks like it's architecturally non-trivial to fix: looks like cargo-dist favors reusable workflows and doesn't have a view of which exact secrets a given reusable workflow needs, so it shares all of them with secrets: inherit:

https://github.com/astral-sh/cargo-dist/blob/622170f09a1521bc0782332317076e4805737cef/cargo-dist/templates/ci/github/release.yml.j2#L478

This makes sense as a constraint there, but it also means that I can't remediate these directly. I'm inclined to WONTFIX them for now, since handling secret inheritance with full generality in cargo-dist seems complicated 🙂