Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122894
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <089e6466-540b-4d86-8cf4-1a6b5506efed@rwec.co.uk>
Date: Tue, 2 Apr 2024 20:02:54 +0000
Message-ID: <CAEKnhAFxHm_QZpWK_FSxBa-+F-G-J4BOiv+0F_3_y6azJTiaVg@mail.gmail.com>
Subject: Re: [PHP-DEV] Requiring GPG Commit Signing
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000227b520615229818"
From: bukka@php.net (Jakub Zelenka)

--000000000000227b520615229818
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 8:45=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rwe=
c.co.uk>
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.
>
>
> 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.
>
> 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.
>
> 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.
>

Nice comparison. Fully agree with that. I would add that potentially even
more important point than auditability is possibility to revoke access of
the compromised account as otherwise you can't easily identify such account
and prevent further issues.

Regards

Jakub

--000000000000227b520615229818
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Apr 2, 2024 at 8:45=E2=80=AFPM Ro=
wan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@r=
wec.co.uk</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 02/04/2024 20:02, Ilija Tovilo
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>But, does it matter? I&#39;m not sure we look at some commits cl=
oser than
others, based on its author. It&#39;s true that it might be easier to
identify malicious commits if they all come from the same user, but it
wouldn&#39;t prevent them.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>It&#39;s like the difference between stealing someone&#39;s credit c=
ard,
      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&#39;ll have a hard job even working out
      who to contact.</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.</p>
    <p>I agree it&#39;s not a complete solution, but no security measure is=
;
      it&#39;s always about reducing the attack surface or limiting the
      damage.</p></div></blockquote><div><br></div><div>Nice comparison. Fu=
lly agree with that. I would add that potentially even more important point=
 than auditability is possibility to revoke access of the compromised accou=
nt as otherwise you can&#39;t easily identify such account and prevent furt=
her issues.</div><div><br></div><div>Regards</div><div><br></div><div>Jakub=
</div><div>=C2=A0</div></div></div>

--000000000000227b520615229818--