chore: Set permissions for GitHub actions

[naveensrinivasan]

Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.

• Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions

https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

Signed-off-by: naveen [email protected]

[waylan]

Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

I find this amusing. The article above goes through the explanation of how an attacker could use a PR to run code which gives them write access to the repo. It then states that the way to prevent this is to review the PR before allowing the workflow to run (which I always do). But it then acknowledges that this is prone to human error and so you should set permissions.

The problem with that reasoning is that a PR could just as easily remove the permissions which have been added here. And catching that change is just as prone to human error. In other words, this solves nothing.

I suppose we do get one benefit. As the workflow is set to read-only, I do not need to explicitly approve it before it runs. At least I assume that is the case as I did not need to approve the workflow for this PR. It is curious though, that the workflows in .github/workflows/process.yml also ran without my explicit approval and they have not had their permissions set. So maybe the difference was that there were no changes to the code? If so, then this change is useless.

@naveensrinivasan any reason why you didn't also set the permissions on .github/workflows/process.yml?

[naveensrinivasan]

Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

I find this amusing. The article above goes through the explanation of how an attacker could use a PR to run code which gives them write access to the repo. It then states that the way to prevent this is to review the PR before allowing the workflow to run (which I always do). But it then acknowledges that this is prone to human error and so you should set permissions.

The problem with that reasoning is that a PR could just as easily remove the permissions which have been added here. And catching that change is just as prone to human error. In other words, this solves nothing.

I suppose we do get one benefit. As the workflow is set to read-only, I do not need to explicitly approve it before it runs. At least I assume that is the case as I did not need to approve the workflow for this PR. It is curious though, that the workflows in .github/workflows/process.yml also ran without my explicit approval and they have not had their permissions set. So maybe the difference was that there were no changes to the code? If so, then this change is useless.

@naveensrinivasan any reason why you didn't also set the permissions on .github/workflows/process.yml?

It was easy to fix one TBH. Thanks