Remove persist-credentials or change the default to false
#485
Comments
|
I can't believe the default is to persist credentials and expose them to other jobs :( this is a major security issue. Just as a heads up for anyone stumbling upon this issue:
So if you want to harden security, apart from setting See https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ for reference. |
|
+1 |
|
Agreed this seems a severe security issue, because it means any workflow using @haampie IIUC it is a problem also with no ssh authentication (the default). The GitHub token is given only to this action and maybe a few other actions/* actions ( In other words,
So, depending on whether the token is explicitly passed to some action:
I guess GitHub sees setting token permissions as the more general solution. https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ also has a mention related to this, search for
|
|
+1 |
briansmith
changed the title
persist-credentials removed or false by defaultpersist-credentials or change the default to false
|
I updated the issue title since v3 and v4 have already shipped, so asking for a new v3 doesn't make sense. |
|
Fast forward to 2024, and we have https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/
@ericsciple could you please take this issue seriously and disable persisting credentials to disk? |
persist-credentials defaults to true (see actions/checkout#485). It looks like pull_request workflows run without token access, but it's not clear from https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ if that means persist-credentials doesn't leave a secret in the .git directory where a malicious PR could access it.
See: actions/checkout#485 Co-authored-by: alxndrsn <alxndrsn> Co-authored-by: Steven <[email protected]>
|
Not sure this is actually necessary. There seems to be a mismatch between the documentated default and the code As I read the code, the 'persist-credentials' value will be false if the input does not contain a 'persist-credentials' entry. The issue should be changed to a 'fix the documentation' if my understanding is correct. |
Change the default value of persist-credentials setting from true to false to reduce the risk of unintentionally exposing the GITHUB_TOKEN secret. Fixes: actions#485 Signed-off-by: Michi Mutsuzaki <[email protected]>
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions. The only exceptions are for the release job, which wants to push a tag and create a branch, each of which explicitly persist credentials now and explains why in a comment.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions. The only exceptions are for the release job, which wants to push a tag and create a branch, each of which explicitly persist credentials now and explain why in a comment.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
See actions/checkout#485 and https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ In short, it is a terrible idea to persist even our default credentials after checkout. There's no call for that, so we will now set `persist-credentials: false` on all checkout actions.
Currently one has to resort to explicitly specifying
persist-credentials: falseto avoid the credentials being persistent. My understanding is that persisting the credentials gives every step in the job that occurs afteractions/checkout@v2implicit access to the token. This is not what people expect and this leads people to write jobs that expose their repo to more risk than they otherwise would.I propose the
persist-credentialsfeature be removed completely and then v3 be released. Otherwise, if that's not practical, then at least the default should be changed tofalse.The text was updated successfully, but these errors were encountered: