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.

[Zombaya]

@sashashura , I noticed you are creating PR's like this to a lot of high profile projects and wanted to express my gratitude for trying to create a safer environment for the general public by having major projects increase the security.

I'm no maintainer to this project, so I will not be able to help with this particular PR but just wanted to send good vibes your direction.

Kudos!

I can see you automated the creation of this PR's a bit, so it might be interesting to add a link to your project in the text of your PRs or star it on your profile in some way so others might contribute or learn from it.

[sashashura]

@Zombaya Thank you. I plan to exterminate this kind of misconfiguration in high profile projects and educate maintainers along the way :) The process is semi-manual and I have automated forking and creating pull requests with github api to speed up the things. It is a mess, maybe one day I'll open source it.

[GrahamCampbell]

Thanks for the feedback. It's a shame that GitHub can't provide more secure defaults, and I'm reluctant to merge this in case there are product changes coming down the line.

[sashashura]

@GrahamCampbell who can review it?

[GrahamCampbell]

I am waiting for feedback from a contact I have at GitHub r.e. this.

[GrahamCampbell]

They have now changed the product: https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/.

[sashashura]

For new orgs/repositories. Which is good in the long term.
However I fail to understand how this PR is hanging for 3 months.
Regardless of what default are, you could flip the setting at any time, but it would break the jobs that require specific write permissions. This PR fixes that. Otherwise there is no difference what GitHub default setting policy is - the branch-alias.yml work with full permissions only.