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. Unless we want to start limiting contributors to people who show up at conferences to do key signings of their GPG keys, I question exactly what this buys the project other than an illusion of security and additional complexity? I couldn’t even really trust Derick to read me his GPG public key character-by-character over the phone now days thanks to AI.
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. Unless we want to start limiting contributors to people who show up at conferences to do key signings of their GPG keys, I question exactly what this buys the project other than an illusion of security and additional complexity? I couldn’t even really trust Derick to read me his GPG public key character-by-character over the phone now days thanks to AI.
It’s not meant to prevent XZ attack. The purpose is really just for the actual contributors to have some assurance that just some random person won’t commit anything in their name just by changing the author of the commit.
See another thread [1] about prevention of the XZ attack - that basically requires moving the actual build to the CI and have the right process to verify it.
> 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:
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:
That’s really unfortunate (why even bother). IMO without some sort of web of trust verification process for GPG, this just feels like added barriers for no actual win. In fact, if anything I think it’s more likely to give the project a false sense of security.
[Resending, because my mail server failed to look up php.net. It looks good now, I apologize for duplicate copies.]
On 4/3/24 19:28, John Coggeshall wrote:
That's really unfortunate (why even bother). IMO without some sort of web of trust verification process for GPG, this just feels like added barriers for no actual win. In fact, if anything I think it's more likely to give the project a false sense of security.
While it does not *prevent* any attacks, it possibly simplifies an investigation:
For example: Did John Doe suddenly start signing with a new key? Or was only a single commit signed with a different key?
If John uses a different key for each computer (e.g. one for the work laptop and one for the private gaming computer), then the signature possibly allows determining which machine was compromised.
These are useful signals to determine the possible scope of an attack.