[TheDong]

Let me ask a few questions about this scheme:

1. What happens when someone needs to resolve a merge conflict involving your commit? Let's say I maintain a fork of an open source repo to add some feature, and I periodically merge back in upstream changes... that necessarily involves resolving conflicts. By default, git retains author ownership, and now the commit is unsigned, but it's really your work. What do we do? Do I have to use a custom merge flow that also rewrites authorship from "Alice <[e-mail]>" to "Alice <[e-mail]>"?

2. What happens if your gpg key is compromised or expires? Are all your previous repos now invalid? I can't fork it because it contains a commit authored by you, but with a revoked or expired gpg key?

3. What happens to previous commits if I enable this feature? Can all my unsigned commits no longer be pushed to github? I made a commit in a project at work 5 years ago with my email, but didn't sign it.. if that company wants to open source that project on github, do they now have to rewrite history to change the author on my unsigned commits?

4. What does the "squash merge" button on github PRs do for your PRs?

[hgomersall]

We've adopted this policy internally. It largely requires using the proper git workflow, rather than (in our case) gitlab's GUI flow, though we make an exception for a simple merge (I think it's verifiable that no code is added).

The check is that commits at the point of merge have a valid signature. Historical commits are part of the history and as such cannot be changed without an additional commit (with a valid signature). Previous unsigned commits are deemed trusted at the point you begin signing and checking.

Squash merge breaks stuff and shouldn't be used. To complete things, the restricted set of operations exposed through the GUI should sign using gitlab's or github's key (or some accepted bot key we've set), with the check happening on the input commits, but AFAICT that's not supported yet.

[eurasiantiger]

And now we’re on the fast track to adopt a blockchain as a tamper evident mechanism.

[jhugo]

git is effectively a blockchain. Trying to use a blockchain for this has many of the same problems as described in GP's comment.

[3np]

A blockchain could be useful for proving a commit was not done significantly before or after the claimed timestamp, and (depending on how you do it) non-repudiation.

IMO I don't see how this is desirable enough to be worth it.

Wider adoption of GPG signatures would be much more impactful.

It could make sense to use a blockchain for key distribution/key discovery/revocation, effectively as a replacement of PKI, though.