I was recently asked about whether signed commits would have prevented the #xz attack. The tl;dr is "no."
It's very important that the non #infosec community understands what a #digitalsignature does and doen't do. The notion that there's a #silverbullet for every technical, social, or trust problem is part of what makes #cybersecurity so hard to implement well.
#OpenPGP signatures rely on the system clock for setting the timestamp of a signature when signing the metadata and content of a commit. The author and committer dates can both legitimately differ from the timestamp of the signature for a number of reasons, or be made exactly the same rather trivially.
#Git history is a directed acyclic graph, not a cryptographic #blockchain, so a commit is just the delta between objects in the current treeish and the parent treeish in the graph. The signed metadata includes the current parent's SHA hash, but there's nothing stopping you from moving commits around and re-signing the new commits. If you couldn't do this, then you couldn't rebase, squash, do non-fast-forward merges, or cherry-pick.
This doesn't mean you can forge someone else's signature without access to their key material, but the attack wasn't the result of forged metadata or account impersonation. Signing wouldn't prevent commits by someone with commit access to the repository; it would just show that commits associated with Jia Tan were also signed by Jia Tan's private key. That provides no useful security control here. This was not a Git problem.
