Require signed commits

[hughsie]

In light of the xz issue recently, I wondered if we should enforce signed commits, e.g. git config commit.gpgsign true -- maybe it's something we could add to ./contrib/setup? I don't know if that complicates things from a new contributor point of view, but givem @superm1 and I seem to be doing a lot of the heavy lifting just asking the core contributors to have this turned on would be a great start.

[superm1]

I don't always have my gpg key on me. It would certainly make things a lot more difficult for me.

I think it also would break things like squash and rebase making the project more annoying for pull requests.

I'm of the opinion it's not worth it.

[superm1]

The other thing is having signed commits turned on doesn't prevent a long drawn out attack like xz, it just is a bigger barrier to entry to genuine contributors.

I think the only thing it really helps is to prove no identity theft occurred.

[hughsie]

I think the only thing it really helps is to prove no identity theft occurred.

Agreed. Maybe we ask that it's enabled when possible, but don't hard require it.

[superm1]

Really what you need is that it's signed by other people to be a strong key.

I don't want to make people do that. It's a really annoying process (IMO).

[YehezkelShB]

In case of GitHub, won't GitHub add another layer here, requiring people to have their key connected to their GitHub confirmed email, so it's strong enough even without getting other people to sign the key? https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#statuses-with-vigilant-mode-enabled

[superm1]

In case of GitHub, won't GitHub add another layer here, requiring people to have their key connected to their GitHub confirmed email, so it's strong enough even without getting other people to sign the key? https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#statuses-with-vigilant-mode-enabled

But what does that really add? A bad actor can make a GitHub account and associate a gpg key. It just proves the commit was verified to come from the bad actor. So I suppose it is only useful to deter identity theft.

Signing the key however I feel does make it stronger as there are people who really have interacted physically with a person. A lot tougher for a bad actor.

[YehezkelShB]

Ah, I thought we already assumed this is only for verifying the source of the commits comes from the same specific user (prevent identity theft), and I wanted to mention that with GitHub we probably don't need other people to sign the key to know it's connected to the user (at least to some degree; it won't be safer than the security of the user's profile in GitHub, naturally).

I see your point with signed key to give an additional safety against bad actors, but if we already agreed we won't ask for this as it's too much of a burden for many of the (potential) contributors, it isn't relevant anyway.

(And sorry, but I can't resist the urge to mention: https://xkcd.com/364/)

[rcalixte]

Just chiming in out of experience, I started using this feature by default myself once SSH keys were enabled for support when signing commits. It eases a lot of the burdens that GPG can sometimes introduce. GitHub's documentation attached below but this is supported on most other platforms as well since it is built into git as of v2.34.

In terms of making it a strong key, passphrases would be recommended and an agent can be used to alleviate the burden of management there as well.

With regards to squashing and rebasing, these are signed as well depending on your configuration and approach. Local rebases for me are always signed and when I merge PRs, I squash and merge which GitHub will sign when adding to the commit tree, even if the commits in the pull request are not signed. Just two cents from a wanderer here 👋🏼, if this can be introduced without impacting the core contributors too much, I think it's worth it.

GitHub Documentation - Signing Commits