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.

[sashashura]

Do I need to do it against dev?

[sashashura]

@parrt @hs-apotell Could you please review?

[sashashura]

An example of a recent workflow run with unrestricted permissions:

[parrt]

Hi! That change seems like a reasonable idea and simple enough. I guess we protecting against an action that somehow managed to overwrite the repository or related artifacts?

[sashashura]

It protects from the repository compromise in case of a toolchain/dependency compromise. Of couse if your dependency is compromised you may build a compromised release. Although release builds happen not often, in this attack scenario, if a dependency is compromised for a short period of time, before it is noticed by maintainers, it may be enough for the workflow to start (it starts on every push). If permissions are unrestricted, the compromised tool/dependency may modify the repository content and even previously released artifacts.
To put it the other way, all-write permissions are like sudo. Why running builds with sudo unnecessarily? By restricting permissions the potential impact of compromised dependency is reduced.