Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122907
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-ID: <17cad25d-bb3e-4be4-a875-a399c64f605e@app.fastmail.com>
In-Reply-To: <089e6466-540b-4d86-8cf4-1a6b5506efed@rwec.co.uk>
References: <3e988b3b-65b8-13d3-16cf-1296bfdd7ed2@php.net>
 <CAPyj-LC9Ygr0vNB3RyTKmmYmq1VbNgzDS_J3bq6NaoXD1YaMhQ@mail.gmail.com>
 <33406173-693c-44c2-a378-fff49751f3b4@rwec.co.uk>
 <CAPyj-LDh7K=cGcxX1qpY7=SYGOdOo0y-QAQjorhRoeqO2ni96A@mail.gmail.com>
 <089e6466-540b-4d86-8cf4-1a6b5506efed@rwec.co.uk>
Date: Wed, 03 Apr 2024 08:41:06 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Requiring GPG Commit Signing
Content-Type: multipart/alternative;
 boundary=10f8899a49364bfcbaa4aa598e945e61
From: rob@bottled.codes ("Rob Landers")

--10f8899a49364bfcbaa4aa598e945e61
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024, at 21:40, Rowan Tommins [IMSoP] wrote:
> On 02/04/2024 20:02, Ilija Tovilo wrote:
>> But, does it matter? I'm not sure we look at some commits closer than
>> others, based on its author. It's true that it might be easier to
>> identify malicious commits if they all come from the same user, but it
>> wouldn't prevent them.
>=20
>=20
> It's like the difference between stealing someone's credit card, and c=
loning the card of everyone who comes into the shop: in the first case, =
someone needs to check their credit card statements carefully; in the se=
cond, you'll have a hard job even working out who to contact.
>=20
> Similarly, if you discover a compromised key or signing account, you c=
an look for uses of that key or account, which might be a tiny number fr=
om a non-core contributor; if you discover a compromised account pushing=
 unsigned commits, you have to audit every commit in the repository.
>=20
> I agree it's not a complete solution, but no security measure is; it's=
 always about reducing the attack surface or limiting the damage.
>=20
> Regards,
>=20
> --=20
> Rowan Tommins
> [IMSoP]

FWIW, I store my signing and ssh keys on yubikeys. Even then, when I man=
aged to lose one several years ago, revoking the certificate on GitHub w=
as relatively straightforward. Further, it marked every commit made by t=
hat key (ever) as unverified.

So, in the very least, if a key were to be compromised, any open PRs wou=
ld need to be resigned by the author to get them back in good standing; =
if verified commits are required.=20

This, of course, makes GitHub the "single point of failure." If someone =
were to gain access to my GH (even on an unattended laptop), they could =
add their own keys, and on another computer; log in with another account=
, and then push commits with my email address and their gpg key. GitHub =
would show them as verified (IIRC) and from me. This is by design, since=
 "in theory," I could have pushed my commits to a coworker's git repo, w=
ho then pushed it to GH.

Terrifying stuff... but it is even more terrifying than not having signe=
d commits at all, since literally anyone can push a commit with anyone's=
 name on it and nobody would even know it was a counterfeit. So, at leas=
t requiring signed commits makes the bar that much higher to counterfeit=
/hide malicious commits.

If this stuff terrifies you too, I recommend turning on vigilant mode: h=
ttps://docs.github.com/en/authentication/managing-commit-signature-verif=
ication/displaying-verification-statuses-for-all-of-your-commits

=E2=80=94 Rob
--10f8899a49364bfcbaa4aa598e945e61
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Apr 2, =
2024, at 21:40, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div class=3D"qt-moz-cite-prefix">On 02/04/2=
024 20:02, Ilija Tovilo
      wrote:<br></div><blockquote type=3D"cite" cite=3D"mid:CAPyj-LDh7K=3D=
cGcxX1qpY7=3DSYGOdOo0y-QAQjorhRoeqO2ni96A@mail.gmail.com"><pre>But, does=
 it matter? I'm not sure we look at some commits closer than
others, based on its author. It's true that it might be easier to
identify malicious commits if they all come from the same user, but it
wouldn't prevent them.<br></pre></blockquote><p><br></p><p>It's like the=
 difference between stealing someone's credit card,
      and cloning the card of everyone who comes into the shop: in the
      first case, someone needs to check their credit card statements
      carefully; in the second, you'll have a hard job even working out
      who to contact.<br></p><p>Similarly, if you discover a compromised=
 key or signing account,
      you can look for uses of that key or account, which might be a
      tiny number from a non-core contributor; if you discover a
      compromised account pushing unsigned commits, you have to audit
      every commit in the repository.<br></p><p>I agree it's not a compl=
ete solution, but no security measure is;
      it's always about reducing the attack surface or limiting the
      damage.<br></p><p>Regards,<br></p><pre class=3D"qt-moz-signature" =
cols=3D"72">--=20
Rowan Tommins
[IMSoP]<br></pre></blockquote><div><br></div><div>FWIW, I store my signi=
ng and ssh keys on yubikeys. Even then, when I managed to lose one sever=
al years ago, revoking the certificate on GitHub was relatively straight=
forward. Further, it marked every commit made by that key (ever) as unve=
rified.<br></div><div><br></div><div>So, in the very least, if a key wer=
e to be compromised, any open PRs would need to be resigned by the autho=
r to get them back in good standing; if verified commits are required.&n=
bsp;<br></div><div><br></div><div>This, of course, makes GitHub the "sin=
gle point of failure." If someone were to gain access to my GH (even on =
an unattended laptop), they could add their own keys, and on another com=
puter; log in with another account, and then push commits with my email =
address and their gpg key. GitHub would show them as verified (IIRC) and=
 from me. This is by design, since "in theory," I could have pushed my c=
ommits to a coworker's git repo, who then pushed it to GH.<br></div><div=
><br></div><div>Terrifying stuff... but it is even more terrifying than =
not having signed commits at all, since literally anyone can push a comm=
it with anyone's name on it and nobody would even know it was a counterf=
eit. So, at least requiring signed commits makes the bar that much highe=
r to counterfeit/hide malicious commits.<br></div><div><br></div><div>If=
 this stuff terrifies you too, I recommend turning on vigilant mode:&nbs=
p;<a href=3D"https://docs.github.com/en/authentication/managing-commit-s=
ignature-verification/displaying-verification-statuses-for-all-of-your-c=
ommits">https://docs.github.com/en/authentication/managing-commit-signat=
ure-verification/displaying-verification-statuses-for-all-of-your-commit=
s</a><br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br>=
</div></body></html>
--10f8899a49364bfcbaa4aa598e945e61--