-
Notifications
You must be signed in to change notification settings - Fork 37
[ci] enforce zizmor checks, drop codecov #346
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 2 commits
9a3eb61
8be41c9
3d23a68
7b9ecdb
5b77622
e003d62
2f9df4e
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,6 @@ | ||
| --- | ||
| repos: | ||
| - repo: https://github.com/zizmorcore/zizmor-pre-commit | ||
| rev: 'v1.23.1' | ||
| hooks: | ||
| - id: zizmor | ||
|
Collaborator
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. Are we asking developers to install pre-commit so that they run zizmor on pre-commit? Otherwise, wouldn't it be better to just install and run the zizmor CLI, or to use zizmorcore/zizmore-action? This is adding pre-commit as a dependency in the chain. Also the pre-commit package being installed here also isn't pinned to a commit hash.
Collaborator
Author
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. It's convenient to be able to run I chose a general task runner like It's convenient to have those things bundled together, and If you'd prefer not to have this here I'm fine to switch to the
The I'm unsure how tightly that controls the Or did you mean by this comment that you'd want the
Collaborator
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. I don't have a super strong position on whether we use the tools directly or if we use pre-commit. If we do want to use pre-commit, it probably makes sense to document that in
Yes, I think we should pin
Collaborator
Author
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. Ok, I've just pushed a commit pinning the Note that with that change, it'll now need to be manually updated to pull in new versions... I haven't pinned the
https://pypi.org/project/zizmor/#files It's I suspect it's possible to do with platform markers but would be pretty annoying to update. And I REALLY think that'd be overkill, If you want to make any changes to the
Collaborator
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. I think it's fine for PyPI packages to be pinned to versions and not SHA hashes. I'm pretty sure PyPI packages are not mutable. Once you've published a version, you can't publish a new distribution over that version number. The main thing is that anything that installs directly from a GitHub repository needs to be hardened, because GitHub does not do anything like that.
Collaborator
Author
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. Ok thanks, yes I agree we can feel confident about not pinning the Everything else I'm about to write is just for your interest, and shouldn't affect this PR at all.
There are a couple ways this is not technically true:
It's for reasons like this that pinning to a SHA that's a checksum of file contents is safer than pinning to version numbers. There's more discussion about this here:
But still, anyway, the current state of this PR is more than enough for our purposes here and a net improvement in this repo's security posture. |
||

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels a little like overkill to me. Feels like setting to
readexplicitly here should be fine? Seems like every job is going to need it anyways, and as a baseline, a job withreadshouldn't be in danger of doing something problematic.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
re-actors/alls-greenjob in this workflow, for example, does not need to be able to read the repo's contents, only the statuses of workflows.As a general rule I still prefer this pattern of zeroing out the permissions for the workflow and having to opt in each job with only the permissions it needs, but I'm fine to switch these to
read. This is a public repo so allowingcontents: readwould be totally fine.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed that change in 3d23a68