[Feature request] Require signed commits from maintainers/collaborators

[pnacht]

Select Topic Area

Product Feedback

Body

There is a branch protection rule (and equivalent repository rule) to require that all commits be cryptographically signed.

This setting is a tough sell for projects that accept external contributions, since basically nobody signs commits. So a project would have to educate approximately every single contributor how to set up commit signing.

Also, the benefit of signed commits for external contributors is questionable: you (the maintainer) don't know who this person is, so you probably shouldn't trust them regardless of whether they sign their commits.

The only case where it would help is if the project has a highly-engaged and trusted external contributor. An attacker could hijack this user's account to send a malicious PR. If that contributor is forced to sign their commits, it may be possible to detect that the PR is fraudulent. But this is something of an edge case.

However, ensuring maintainers/collaborators sign their commits is much more valuable. These are people that are explicitly trusted: "guaranteeing" that "their" commits are actually theirs is self-evidently useful.

I'd therefore love to see a feature requiring that a repository's maintainers/collaborators must sign all their commits. This could either be a branch protection rule (or equivalent repository rule) or a repository/organization-wide configuration.

[pnacht]

This doesn't really answer my concern. That link explains how to sign commits. I already know how to do that.

My feature request is an organization or repository setting to require that all commits coming from maintainers/collaborators must be signed (with a verified key), while allowing commits coming from external contributors to remain unsigned.

[DNin01]

Branch protections and rulesets don't apply to branches on forks of their repository, meaning external contributors won't need to follow any rules such as signing commits on their fork.

And as well, if I'm not mistaken (I've never seen a "require signed commits" protection in action so I'm not sure), when you merge the pull request, it will probably create a signed merge commit, whether the commits in the downstream branch (the PR) were signed or not, and doesn't include signatures from the commits that were part of the merge commit. This signed commit can then pass the rule, so I think branch protections should already cover your requested use case. Does that solve it?

[pnacht]

Branch protections and rulesets don't apply to branches on forks of their repository, meaning external contributors won't need to follow any rules such as signing commits on their fork.

They won't apply as long as the code is only on the fork and hasn't been submitted as a PR, correct.

And as well, if I'm not mistaken (I've never seen a "require signed commits" protection in action so I'm not sure), when you merge the pull request, it will probably create a signed merge commit, whether the commits in the downstream branch (the PR) were signed or not, and doesn't include signatures from the commits that were part of the merge commit. This signed commit can then pass the rule, so I think branch protections should already cover your requested use case. Does that solve it?

Per GitHub docs, you are correct that this would work using a merge commit, but not using the other methods (squash and rebase).

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits:

[...] You can also merge signed and verified commits into the branch using a pull request on GitHub. However, you cannot squash and merge a pull request into the branch on GitHub unless you are the author of the pull request. [...]

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github:

When using the Rebase and Merge option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification. [...]

[ychin]

And as well, if I'm not mistaken (I've never seen a "require signed commits" protection in action so I'm not sure), when you merge the pull request, it will probably create a signed merge commit, whether the commits in the downstream branch (the PR) were signed or not, and doesn't include signatures from the commits that were part of the merge commit. This signed commit can then pass the rule, so I think branch protections should already cover your requested use case. Does that solve it?

It does not work like that. The branch protection rule requires all commits to be signed, even the ones in the pull requests. It doesn't just require the final merge commit to be signed. For open source projects I do agree that this feature is unusable because very few open source projects would require every contributor to sign their commits. I agree with OP that just requiring maintainers to sign their commits is a good compromise and actually usable.