ci: add zizmor check and configuration

[winterqt]

zizmor is a tool that uses static analysis to find potential security issues in GitHub Actions 0. (Yes, it's a bit absurd that GitHub made a CI system so complicated that tools like this were created, but I digress.)

Given our increase in GHA usage recently, I think this is a good step towards keeping our security posture in tip-top shape. (It also keeps with the theme of automating as many things as possible!)

There are a few false positives (stemming from two rules), so I've excluded them per-usage (well, mostly, see 1) instead of globally or per-file, so that new usages of them get caught so we can determine if we can avoid using the footgun(s), or if we should ignore it.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[winterqt]

As part of this PR being merged, I would like to enable code scanning merge protection, so that PRs that do not pass zimor's checks will not be able to be merged.

Given that @infinisil is an org owner alongside myself, a +1 should be sufficient for either of us to enable this setting while merging.

[LeSuisse]

Thanks for dealing with that, it was on my todo list since the moment I added the zizmor package into nixpkgs but I did not find the time to do it since then 💚

[winterqt]

Still need to get to this, but want to fix up some things on Zizmor's end first.

[wolfgangwalther]

With the recent changes around running more checks via treefmt (#405684) and future changes about being able to run most of CI locally (#404466), we need to rethink the workflow part of this. Since this is static analysis of code, I think it would fit in with treefmt very nicely.

I'm just not sure how we can report results to upload to GitHub from fmt.check, I have not looked into treefmt / treefmt-nix too much, yet.

[wolfgangwalther]

With the recent changes around running more checks via treefmt (#405684) and future changes about being able to run most of CI locally (#404466), we need to rethink the workflow part of this. Since this is static analysis of code, I think it would fit in with treefmt very nicely.

treefmt-nix is now shipping zizmor: numtide/treefmt-nix#354

[LeSuisse]

@winterqt Are you fine with me taking over the PR? I would like to rebase it, leverage treefmt and deal with the remaining changes so we can hopefully merge it.

[winterqt]

Go for it, @LeSuisse!

[qweered]

@LeSuisse Have you been able to work on it yet? I am also intrested in implementing this

[LeSuisse]

Rebased the changes, resolved the conflicts and the remaining Zizmor issues. The Zizmor workflow has been replaced by the use of treefmt.

[wolfgangwalther]

LGTM; thank you!

Found a typo in the commit message of the second commit: "Explainations" -> "Explanations".

[LeSuisse]

Typo fixed, thanks!

The recent changes done on the CI have helped quite a lot to make this as straightforward as possible 💚

[nixpkgs-ci]

Successfully created backport PR for release-25.05:

• [Backport release-25.05] ci: add zizmor check and configuration #456116

[philiptaron]

I'm stoked to see this land. Thanks to @winterqt and @LeSuisse for authorship!

[philiptaron]

This was the source of https://ptrpa.ws/nixpkgs-actions-abuse, correct?

[wolfgangwalther]

One of the 3 factors, yes. Since we can not get rid of pull_request_target, we must focus on the other two instead. That trigger being dangerous means we must use it in the safest way possible. We do use explicit trusted/ and untrusted/ folders for all the checkouts to make it obvious when untrusted code is executed. And we committed to move away from Bash recently. I think we're in a good spot.

[arianvp]

Can't we disable this on a per-usage basis? Globally disabling it whilst this is a thing we actually got pwned by seems to kind of defeat the purpose of the tool. I want this to fail hard in CI and have people add a #zizmor-ignore comment if they really want to use dangerous triggers

[wolfgangwalther]

We decided to disable it globally in #396451 (comment). The exclusion list was almost every workflow file back then - so there was really no point in doing it differently.

This is different by now - since we rely much more on re-usable workflows which are triggered in a single parent workflow. Still, we have pull_request_target 4x, and pull_request only a single time. The latter is an exception for a very specific use-case.

Due to the way that the workflows are structured:

• New jobs will not be added in new workflow files, so people are not going to write new triggers the majority of time. When they do, they are likely implementing something that needs permissions, because it's something outside the regular PR workflow - which means it's some kind of automation. But even for more automation, it's unlikely that anyone will actually write a new workflow with pull_request_target or pull_request.
• Contributors to those files will need to know that they are actually in a pull_request_target context - despite this trigger being written in a separate file. So they can't really tell from the on: part of the workflow file they are in anyway, due to those re-usable workflows. Also, these workflows are designed to be run in both triggers, depending on the parent workflow.

a thing we actually got pwned by

Again, no. We were not pwned by using this trigger. We were pwned by using it wrong. The idea of marking this trigger "dangerous" is kinda stupid to begin with. If you were to never use this kind of trigger, then, sure, you have fewer risks. But also, you can't make use of any secrets or elevated permissions in CI. So once you start putting secrets into GHA configuration, you'll have to start thinking about this. Is putting secrets in via GHA's configuration specifically designed for that considered "bad practice"? I don't think so.

---

I won't oppose somebody changing this to put these comments in these 4 places - but I'll also say that this won't make any meaningful difference for security. If you feel better when removing this global option, but adding individual disable comments - then I'm afraid you are not seeing the real threats that we have to deal with for CI: Injection and running untrusted code. These are far more likely to mess up.

[LeSuisse]

Side note, I also noticed we have one usage of workflow_run which can also be problematic

Maybe we should also add a note in .github/workflows/README.md?

https://securitylab.github.com/resources/github-actions-new-patterns-and-mitigations/#security-boundaries-and-workflow_run-event

[wolfgangwalther]

We will very likely have more workflow_run and also issue_comment soon. All of which are giving access to secrets, yes.

The default assumption for everything in CI must be that it will run in these contexts, where elevated permissions are possible and secrets are available.

To put it differently: Of the 16 workflow files we have, only two workflow files can be considered "safe" according to the "dangerous triggers" definition. All other 14 workflow files have access to secrets and permissions.