CI: Hashpin github-actions with dangerous permissions #7153
Conversation
This includes actions with write permisisons but also actions that have access to critical secrets, such as the `secrets.ADMIN_GITHUB_TOKEN` Signed-off-by: Diogo Teles Sant'Anna <diogoteles@google.com>
|
|
Signed-off-by: Diogo Teles Sant'Anna <diogoteles@google.com>
|
Hey @krassowski, I've updated the PR after a version update dated after my initial PR, and resolved the merge conflicts. It seems like the "Enforce PR label" is still blocking the merge, let me know if there is anything I can do to help solving it. Cheers, |
|
Will we get clever dependabot updates, or will we need to manually update the pins? |
|
Should this be discussed in a team compass repo maybe? For example https://github.com/jupyterlab/team-compass? These actions are used by many Jupyter projects, and if going with these pins then there is no reason for them to be specific to the |
|
|
||
| - name: Build | ||
| uses: ./.github/actions/build-dist | ||
|
|
||
| - uses: actions/download-artifact@v3 | ||
| - uses: actions/download-artifact@9bc31d5ccc31df68ecc42ccf4149144866c47d8a # v3.0.2 |
There was a problem hiding this comment.
So we can't trust GitHub's own actions anymore?
There was a problem hiding this comment.
I don't think we should just "not trust github", the company has huge credibility and should be more trustful than random or less-known workflows. But we must recognize that the security of their actions is held differently than the security of any of their other infrastructures. Their main infrastructure is closed-source and should have their own security (I can't really tell, but we hope (?)); but their actions are just open source repositories (see https://github.com/actions/download-artifact), and could be vulnerable to risks like any others.
In their own documentation, Github mentions that using tag-versioning can be risky even while only using actions from trusted authors.
And besides that, if we're already hash-pinning the other actions that are run in sensitive context, there is also a "why not" factor to also hash-pin the sensitive ones from GitHub.
You'll receive clever dependabot updates! It would update them at the same pace you're already used to, and it would still keep a comment with the human-readable version used =). If you wish, we can also configure it to update all github actions in a single monthly PR, for example.
Let me know if you want my help raising this discussion anywhere else. I'd be happy to help =) |
Closes #7119