GitHub Workflows security hardening

[sashashura]

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted. It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

[lovell]

Hello, thank you for the PR. As you may have noticed this repo is configured to always require manual approval before any workflow runs, but I'd be happy to strengthen this further, especially as this could help improve the security of forks.

The workflows require the ability to create releases and release artefacts, which I think means we'll also require the addition of contents: write at the job level.

[sashashura]

Permissions are not as granular as they could be. contents: write covers all the cases you mentioned.

[sashashura]

But currently I set contents to read. Do I understand correctly that

        env:
          prebuild_upload: ${{ secrets.GITHUB_TOKEN }}
        run: npx prebuild --runtime napi --target 7

creates GitHub release and needs the write permission?

[lovell]

Yes, the prebuild step creates a release (if it doesn't already exist) with the same name as the tag and adds artefacts to that release.

[coveralls]

Coverage remained the same at 100.0% when pulling 7ed78f20cacec5921b8fc1e48e8ed8f80d0eb21c on sashashura:patch-1 into 70e6bb016271ae943d1f7695de8cef7559ffbb1a on lovell:main.

[sashashura]

Just for the reference these are current permissions it runs with:

[lovell]

Thank you!