-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
ci: add zizmor check and configuration #396451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| # This file defines the ignore rules for zizmor. | ||
| # | ||
| # For rules that contain a high number of false positives, prefer listing them here | ||
| # instead of adding ignore comments. Note that zizmor cannot ignore by line-within-a-string, so | ||
| # there are some ignore items that encompass multiple problems within one `run` block. An issue | ||
| # tracking this is at https://github.com/woodruffw/zizmor/issues/648. | ||
| # | ||
| # For more info, see the documentation: https://woodruffw.github.io/zizmor/usage/#ignoring-results | ||
|
|
||
| rules: | ||
| dangerous-triggers: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was the source of https://ptrpa.ws/nixpkgs-actions-abuse, correct?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One of the 3 factors, yes. Since we can not get rid of
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 Due to the way that the workflows are structured:
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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Side note, I also noticed we have one usage of Maybe we should also add a note in
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We will very likely have more 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. |
||
| disable: true | ||
Uh oh!
There was an error while loading. Please reload this page.