SEC: several vulnerabilities detected by zizmor

[neutrinoceros]

I would like to propose enabling continuous security scanning with zizmor given the critical place this repo sits in the ecosystem's suplly chain.
At the time of opening, most (possibly all) existing vulnerabilities can be fixed automatically or with minimal effort, and I've started issuing PRs in that direction.

Linked PRs

• SEC: add a 7 days cooldown period to dependabot settings #2766
• SEC: pin gha dependencies to exact git shas #2767
• Update and pin GitHub Actions + pre-commit hooks #2744
• SEC: avoid leaking credentials in GHA #2769
• SEC: disable default gha permissions #2771
• Add zizmor as a CI check #2776

[neutrinoceros]

There's an audit I cannot address with just a PR: secrets-outside-env

warning[secrets-outside-env]: secrets referenced without a dedicated environment
  --> ./.github/workflows/update-dependencies.yml:30:21
   |
18 |   update-dependencies:
   |   ------------------- this job
...
30 |         app-id: ${{ secrets.CIBUILDWHEEL_BOT_APP_ID }}
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
   |
   = note: audit confidence → High

warning[secrets-outside-env]: secrets referenced without a dedicated environment
  --> ./.github/workflows/update-dependencies.yml:31:26
   |
18 |   update-dependencies:
   |   ------------------- this job
...
31 |         private-key: ${{ secrets.CIBUILDWHEEL_BOT_APP_PRIVATE_KEY }}
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
   |
   = note: audit confidence → High

remediation is easy, but it does require setting up at least one env at the repo level, which only an admin can do.

[henryiii]

By the way, the biggest security issue is probably one that the tool can't detect. We just directly download python, and don't check to see if the hash of the download matches our expectations. We should record to the hash and do hash checking. Of course, if Python does re-upload a modified binary, which they have done before, that would break us.

[neutrinoceros]

You're right. The GHA ecosystem is actually pretty brittle as a whole and there are many attack vectors we cannot guard against. I don't think that's a good reason not to guard against the ones we can though.

[agriyakhetarpal]

I'd argue that even the checksum verification isn't very useful. It'd be better if we could verify the attestations. Python.org binaries are signed with Sigstore nowadays. We should bake the signature verification at https://www.python.org/downloads/metadata/sigstore/ into our build pipeline, as sigstore-python can be used as a library.

[joerick]

remediation is easy, but it does require setting up at least one env at the repo level, which only an admin can do.

I've created an environment update-dependencies-workflow for that workflow. Should I move the secrets mentioned into that environment and remove them from the repository level?

[agriyakhetarpal]

remediation is easy, but it does require setting up at least one env at the repo level, which only an admin can do.

I've created an environment update-dependencies-workflow for that workflow. Should I move the secrets mentioned into that environment and remove them from the repository level?

Yes, that would work! We also need to specify this environment in the workflow file for that particular job (of course).