use zizmor to lint github action workflows

[keewis]

In times of AI-driven attacks on github actions (where the AI agent drastically reduces the effort needed to attack multiple repositories), it is a good idea to try as much as possible to avoid any of the foot guns that github actions provide.

zizmor is a github actions linter (with autocorrection functionality) that flags many potentially exploitable parts as possible.

For xarray, most of the changes were pinning the actions and limiting the permissions for the default GITHUB_TOKEN.

Note that while I've tried to figure out the needed permissions for each job, I'm not certain I found everything, so merging this may result in breaking CI on main.

I've also created new github environments for the codecov token and the nightly wheels token, which are now duplicated between the environment secrets and the repository secrets. After merging (and making sure the tokens are available as usual) it might be good to remove the repository secrets.

Edit: I've removed the codecov env and instead will ignore the zizmor warning, codecov is not a very sensible secret, and the "deployment" messages in PRs (see below) quickly become annoying.

[keewis]

looks like the deployment messages for codecov may become annoying. This token is not a very sensible secret, so it may also be possible to remove the environment and instead ignore zizmor's warning (codecov is one of the kind of token the warning description explicitly shows how to ignore).

Edit: I've done just that

[dopplershift]

You can now add deployment: false under the environment section to disable these annoying messages.

[VeckoTheGecko]

Looks good to me!

[VeckoTheGecko]

Awesome to have as a hook!

[VeckoTheGecko]

Should we also enforce sha pinning on the repo level?

[keewis]

we can try that after merging this PR

[VeckoTheGecko]

Related: We should also have this for Pixi when prefix-dev/pixi#5786 gets merged and released

[keewis]

yep, we can do that, too. We'll have to be able to disable that for the nightly CI, though, otherwise the early warning system will be a week late.

[VeckoTheGecko]

I was thinking 3 days would be good. I think its ok if our nightly env is a few days late?

[keewis]

I guess so. The hope for using a cooldown is that if there is an attack, waiting for 7 days will allow others with more knowledge to detect and report the problem. Obviously, if everybody is doing this you won't gain anything.

However, my superficial knowledge on this topic is at its limit here, it might be worth raising this kind of question in the scientific-python discord: there are more security-aware folks and the authors of the scientific-python-nightly-wheels action.

[mihaimaruseac]

(drive-by comment from the Discord thread on this): I'm of the opinion that the latest nightly can be used in a very sandboxed, very scoped down job, just to test compatibility but with no acces to anything else. The container where that job runs is deleted after the job runs, so it cannot poison future runs of same or other workflows. Static analysis of the package to detect vulns, exploits, is possible, if wanted

[VeckoTheGecko]

nit: maybe worth moving the zizmor (Rust based) tool further up the pre-commit chain since its quite quick compared to the others

[VeckoTheGecko]

Once that pin is fixed I think its fine.

(so you can verify the pins yourself) uv run https://gist.github.com/VeckoTheGecko/734b10cc78742b354c01055660ddf625 - you may be rate limited by github though zizmor has built in tooling for this it turns out