Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122878
Date: Tue, 2 Apr 2024 10:59:44 -0500
To: Andreas Heigl <andreas@heigl.org>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>
Message-ID: <609B255E-518E-4DAF-B41A-D21A3EBB5B5D@getmailspring.com>
In-Reply-To: <eed6980c-a685-4d31-a354-f8af426137c1@heigl.org>
References: <eed6980c-a685-4d31-a354-f8af426137c1@heigl.org>
Subject: Re: [PHP-DEV] Requiring GPG Commit Signing
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="660c2b70_6b8b4567_c0b9"
From: john@coggeshall.org (John Coggeshall)

--660c2b70_6b8b4567_c0b9
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


> 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.
Just Sayin'
John
--660c2b70_6b8b4567_c0b9
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><blockquote><div><div>So if we want to make sure that something like =
XY doesn't happen, we</div><div>have to add some additional restrictions =
to those GPG keys.</div></div></blockquote><div><br><div>Looks like all t=
hose geeky colleagues of ours back in the day having key-signing parties =
at conferences were on to something, maybe.. </div><br><div>Let's be clea=
r about something -- having GPG key requirements isn't going to help a si=
tuation like XZ. The XZ attack was done by an active maintainer of the pr=
oject (who arguably manipulated the original maintainer of the project to=
 become a maintainer themselves). It was as much a social engineering att=
ack as anything.</div><br><div>Having GPG key requirements is all fine an=
d 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 co=
nferences to do key signings of their GPG keys, I question exactly what t=
his buys the project other than an illusion of security and additional co=
mplexity=3F I couldn't even <em>really</em>&nbsp; trust Derick to read me=
 his GPG public key character-by-character over the phone now days thanks=
 to AI.</div><br><div>Just Sayin'</div><br><div>John</div></div>
--660c2b70_6b8b4567_c0b9--