CI: set minimal permissions on GitHub Workflow

[diogoteles08]

Hi!

I see that your GitHub workflows currently don't specify the permissions of their jobs -- in this way their privileges are being determined by GitHub's defaults. If you define minimal permissions you would be secured against erroneous or malicious actions from external jobs you call from your workflow. It's specially important for the case they get compromised, for example.

The idea would be to set a top-level read-only permission on all workflows, so that it would be inherited by all jobs that don't define job-level permissions. With this setup, any required write permission would be declared only where it's needed, as a job-level permissions.

Setting minimum permissions for workflows is recommended by GitHub itself and also by other security tools, such as Scorecards and StepSecurity.

Let me know what you think about this. I'd be happy to raise a PR with the changes if you agree.

Context

I'm Diogo and I work on Google's Open Source Security Team(GOSST) in cooperation with the Open Source Security Foundation (OpenSSF). My core job is to suggest and implement security changes on widely used open source projects 😊

[gevtushenko]

@trxcllnt could you please take a triage this issue?

[jrhemstad]

Hey @diogoteles08. Thanks for the heads up! We're actually in the process of migrating to an entirely new repo with an entirely new actions setup very soon. We'll definitely be sure to address the issue you raised as part of that migration.

[diogoteles08]

Hey @jrhemstad! Sorry for the delayed reply, but it makes perfect sense to wait for the migration to target this issue.

Does the project have any sort of timeline for this migration?

[jrhemstad]

For my own reference, here is how RAPIDS is setting this in their workflows: https://github.com/rapidsai/shared-workflows/blob/12579029b463eb77ffa8119acd05b02952a1b41e/.github/workflows/conda-cpp-build.yaml#L29-L42

[diogoteles08]

@jrhemstad As an FWI, if you define any permission, all the non-mentioned permissions are automatically set to none(doc ref here), so no need to write all other permissions as none.

That said, what I usually suggest is to set only

permissions:
    contents: read

at the workflow level, and set any other needed permission (as the id-token: write) at job level, like in this example.