On Tue, 2 Apr 2024, John Coggeshall wrote: > > > So if we want to make sure that something like XY doesn't happen, we > > have to add some additional restrictions to those GPG keys. > > Looks like all those geeky colleagues of ours back in the day having > key-signing parties at conferences were on to something, maybe..
> Let's be clear about something -- having GPG key requirements isn't > going to help a situation like XZ. The XZ attack was done by an active > maintainer of the project (who arguably manipulated the original > maintainer of the project to become a maintainer themselves). It was > as much a social engineering attack as anything. > Having GPG key requirements is all fine and dandy I suppose, but my > tongue-in-cheek comment above has a real point behind it: GPG keys > don't mean jack if you can't trust who owns the key. GitHub doesn't show the web of trust anyway, just "verified". Command line GIT doesn't either, just: $ git verify-commit HEAD~1 gpg: Signature made Tue 02 Apr 2024 14:55:21 BST gpg: using RSA key 5A52880781F755608BF815FC910DEB46F53EA312 … gpg: aka "Derick Rethans (GitHub) <git...@derickrethans.nl>" [ultimate] gpg: aka "Derick Rethans (PHP) <der...@php.net>" [ultimate] cheers, Derick
