Set explicit contents: read permissions in CI workflow#36
Set explicit contents: read permissions in CI workflow#36Byron merged 1 commit intoGitoxideLabs:mainfrom
contents: read permissions in CI workflow#36Conversation
Since no other permissions are currently needed in it. This avoids the ambiguous and sometimes greater than intended workflow permissions assigned if no `permissions` key is used. See: https://github.com/github/codeql/blob/main/actions/ql/src/Security/CWE-275/MissingActionsPermissions.md This is similar in motivation to, though much simpler than: GitoxideLabs/gitoxide@f41a58c
Byron
left a comment
There was a problem hiding this comment.
Thanks a lot for continuously improving the project 🙏!
|
Thanks, and no problem! Since GitoxideLabs/cargo-smart-release#48 (comment), I've enabled CodeQL in |
|
As |
This resolves a CodeQL check and is also just a good idea. See GitoxideLabs/prodash#36.
This specifies
contents: readpermissions only forci.yml, since no other permissions are currently needed in it. In so doing, it avoids the ambiguous and sometimes greater than intended workflow permissions assigned if nopermissionskey is used.This is similar in motivation to, though much simpler than, GitoxideLabs/gitoxide@f41a58c (GitoxideLabs/gitoxide#1668).
Although I worked on the workflow in #34, I did not notice that this was missing at that time. But I enabled experimental CodeQL queries for GitHub Actions workflows in my fork, which conveniently found this.
Although CodeQL can be enabled by writing a workflow that runs it (an "advanced" setup), I suggest enabling the default setup, which requires no workflow file, in this repository's security settings. CodeQL doesn't yet have Rust queries, so this would only be for GitHub Actions, for which I think it should not be necessary to go beyond the default setup. (You may also want to enable it in
cargo-smart-release.)By the way, I've found that, at least as things stand now, for GitHub Actions queries, the default setup is in practice more versatile than advanced setups in one important way. Like advanced setups, the default setup allows configuring which suite of queries to run. Since, unlike advanced setups, the default setup requires no workflow file, this makes it easy for an upstream repository and its forks to run different suites, without diverging. For example, I enabled the default setup with the
defaultsuite in gitoxide about 10 days ago, while also running the default setup with thesecurity-extendedsuite in my fork, which includes queries that are more subjective in nature or that may carry more false positives.