Open hoffie opened 3 years ago
Ok. Jekyll is an official action which doesn't require write access --> we could limit it to read easily. name: Sync release to changes and Build and deploy jekyll site are not official, need write access and should be reviewed.
Autobuild is much more complicated and involves a lot more actions. Currently this one is the most dangerous one, I think.
Ok. I've now set the GitHub actions permissions to be more restrictive. However, we would still need to do the verification you mentioned and start pinning by hash.
Comment by @hoffie in https://github.com/jamulussoftware/jamulus/pull/2527#discussion_r830526985 related to my suggestion of adding hash verification:
Well, but where do I get the hash from in the first place? I would have to download from the very same source, so the only protection benefit would be a benefit over time, i.e. if Google became malicious or a malicious actor could replace the file there. We aren't handling that attack vector anywhere else either (Qt, choco, pip, Android SDK contents, ...), do we?
I'm not opposed to doing that per-se, but I'd rather have a discussion and do it in all places if we decide to do it. Remember that it will carry a rather big maintenance burden though.
I think the current consensus is:
Ah, now I understand what you're after. :)
This issue was mainly created for the referenced Github actions. The idea is to use hashes here in order to do version pinning on immutable versions (v1.2.3 are tags which are mutable, IIRC).
I think we have to distinguish several scenarios:
Pinning Github action references by commit hash is trivial as it's designed to be done that way. Pinning external sources (e.g. curl/wget downloads or even artifacts from downloader tools such as SDK manager, aqt, ...) may be way harder.
I've now locked down the allowed actions on the repo:
similar to the website.
Note: Since the CI didn't start when I specifically allowed an action user/repo@*
, I've now allowed actions based on users user/**
. syntax. This should be a good tradeoff.
I‘ve now set the workflow read only permission as my PR got merged.
@ann0see is this something that can be picked up for 3.11.0?
I believe especially the website needs review. Tagging it for the next release is certainly possible
Detagging and moving to triage.
Ok. Enabled some more dependabot settings for automatic dependency scanning and github actions. Let's see what it does.
We are using Github Actions in several places:
We are not only using official Github-provided Actions there, but also multiple third-party actions (see below). I am not seeing any use of the
permission:
keyword there, implying that they run with default permissions. This means that those actions have access to a GITHUB_TOKEN with read and write permission to the relevant repo, as far as I understand.I have reviewed the following docs and articles: https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ https://francoisbest.com/posts/2020/the-security-of-github-actions
My conclusion is that we should do the following:
Note: I'm little worried about Github-official actions such as
actions/
orgithub/
(we are trusting Github anyway!) or actions for other large open source projects with high reputation (ruby/
), but I do worry about actions by third-party persons or orgs which we (or at least I?) don't know.Not sure, if/when I'll have time for further work on this. Feel free to comment here and take over.
cc @jamulussoftware/maindevelopers @nefarius2001
See also: https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies