Workflow Permissions Should Be Least-Privileged

[commonsensesoftware]

The template instructions indicate that when setting up a new repository:

_Set "Workflow permissions" to "Read and write permissions" in the repository settings._

This is unnecessarily permissive and applies to all repositories under the account or organization. The required permissions can easily be added to the workflow configuration. This approach would have the added benefit of not requiring the author to change their settings.

The following permissions can be added to a job:

jobs:
  i-d-job:
    permissions:
      contents: write
      pull-requests: write

contents: write is the bare minimum to add and push content, including new branches. If PRs will be created, then pull-requests: write should be added; otherwise, it may not be needed. It looked like the archive workflow might be working with PRs, but perhaps it only needs read access. The ghpages.yml workflow might also need or want pages: write.

I have successfully applied these changes to my workflows without issue, while my account settings only allow read permissions on the token by default. If this change were applied, it should reduce the manual operations down to a single step.

[martinthomson]

I did not know that was possible. This is very useful feedback. With pages: write I think that I can speed up pages deployment, but that will take me a little bit of time to work through. I support markdown pages, so that means running jekyll and the page generation stuff requires a bunch of additional steps.

I might take a little time to implement this. If you feel adventurous, maybe you might consider sending me a pull request...

[commonsensesoftware]

I completely spaced and forgot to include useful links to the documentation:

• https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
• https://docs.github.com/en/actions/security-guides/automatic-token-authentication

If I can get my head wrapped around everything that is required, I'll see about taking a crack at a PR. It probably makes sense for me to explore my own repo, get it working, and dial it back to the bare minimum. There will probably be a little trial by fire to see what breaks if a specific permission is not enabled. Honestly, it doesn't look like a whole a lot is necessary.

[martinthomson]

Thanks for the pointers, if you don't get around to it, at least I know where to start now.

[commonsensesoftware]

I've reduced my workflows down to:

jobs:
  i-d-job:
    permissions:
      contents: write

Everything is still working. I didn't see anything that used the GitHub CLI or Pull Requests. There's a couple places that use the GitHub API directly, but they all seem to be read-only (which should work without any change).

There seems to be only 4 touch points so the changes and PR part are pretty trivial. I'm not sure how you test this though. I can't say that I've used a GitHub repository as a template. Is there a way to check things end-to-end before approving the forthcoming PR?