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]

@jrfnl @gsherwood could you please review?

[sashashura]

An example of a workflow run with unrestricted permissions:

[jrfnl]

@sashashura No. Sorry, but a first time contribution to a repo from someone who's never interacted with the repo before, who has no (public) history on Git (and IIRC when I first looked when the PR was originally pulled, a public history, with no contributions) and who claims something is a security improvement raises all sorts of questions and suspicions for me.

I will not review this PR. I will do my own research when I find the time and then I'll see.

[sashashura]

ok

[sashashura]

I mean I provided some links you can read more about it and make your own judgement. I understand open source is after work activity, but it just two months passed and this is the first reply I got 😄

[jrfnl]

Yeah so ? If you understand open source, you should know not to whine about that (aside from that: I'm not the maintainer).
Also links provided by an OP I don't trust, means I don't trust those links either.

[TimWolla]

who claims something is a security improvement raises all sorts of questions and suspicions for me.

FWIW: The claims are correct. The same effective change was also applied to PHP itself in php/php-src@1d45ca5.

means I don't trust those links either.

Those go directly to GitHub's documentation, not some third party resource.