[BUG]: Hash pin github workflow dependencies

[joycebrum]

Required prerequisites

• [X] Make sure you've read the documentation. Your issue may be addressed there.
• [X] Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
• [X] Consider asking first in the Gitter chat room or in a Discussion.

What version (or hash if on master) of pybind11 are you using?

849322806cd4b3697ad1d35eedd6d0352c5f267a

Problem description

Description

I would like to suggest another security practice recommended by the GitHub itself and the OpenSSF Scorecard which is to hash pin the project's CI dependencies to prevent dependency-confusion, typosquatting and tag renaming attacks. This means:

• Hash pinning GitHub Workflow actions.
• Using --require-hashes on pip installs.

Although the actions that need to be hash pinned on pybind11 are Github Owned Actions, it is still recommended to hash pin them since they are open sourced and are exposed to the same threat vectors any open source project is. Besides, this is currently the only way of using github actions as immutable releases.

Also it might be important to notice that the dependabot, that is already enabled, is able to update both the hash and the comment version related to it.

Let me know if you are open to evaluate those changes and I'll submit the PR ASAP.

Any questions or concerns just let me know. Thanks!

Additional Context

A tag renaming attack is a type of attack whereby an attacker:

• Hijack an action.
• Upload a malicious version.
• Replace existing tags with malicious versions.

Regarding the attacks package managers are exposed to:

A dependency-confusion attack occurs when an attacker:

• Find the name of a package that the victims wants to install
• Create an identically named package and publish it under the public or default registry.
• Assign the package with a higher version number to trick the package manager tool to download it from the public repo.

A typosquatting attack is a type of attack whereby an attacker:

• Create a malicious package
• Publish it with a similar name of a known package (example: numpi instead of numpy)

Reproducible example code

No response

Is this a regression? Put the last known working version here if it is.

Not a regression

[diogoteles08]

Hi! I'm Diogo and I work along with Joyce in Google’s Open Source Security Team.

I'm following up this issue because it's been idle for a while, and also because our approaches around pinned dependencies changed a bit since she opened this issue. Now we won't suggest that you hash-pin all of your workflows dependencies, but only the dependencies that have access to privileged permissions, secrets or produce sensible artifacts.

That said, we'd change the scope of this issue to suggest the hash pinning of the workflows:

• labeler.yml - which has pull-requests: write (which allows approving pull requests or pushing to them) and the action is pointing to @main, which is veery unstable and any malicious change could directly affect your project or your users.
• pip.yml - which has access to secrets and is responsible for the production and publishing of your releases. I'd recommend pinning the dependencies on the jobs packaging and upload, both hashpinning the github actions dependencies and installing pip dependencies using --require-hashes.

Hope this comment helps to explain our motivation here =)

Cheers,