Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122859
Precedence: bulk
MIME-Version: 1.0
References: <AM8P250MB01705B564C0F9B2F460F56B0E2392@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <9008050F-4EE1-4E19-B513-654602E118A7@benramsey.com> <CADyq6sLr=Zv0OmL55na0c6kGkaxvy9A8fJhptn71si8u7rzedQ@mail.gmail.com>
 <CAEKnhAGmDRMypM=fsWAroC6M6JcbwQRf7HYbb7n3GPNVQGvXjA@mail.gmail.com> <95c92b6a-6788-fddb-a130-e4d122338b68@php.net>
In-Reply-To: <95c92b6a-6788-fddb-a130-e4d122338b68@php.net>
Date: Tue, 2 Apr 2024 13:52:28 +0000
Message-ID: <CAEKnhAG4AYy9wPzuVq3y_hqfjcWMDi8HtCkVQyL9Txoqogwz7A@mail.gmail.com>
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: Derick Rethans <derick@php.net>
Cc: Marco Pivetta <ocramius@gmail.com>, Ben Ramsey <ben@benramsey.com>, 
	Bob Weinand <bobwei9@hotmail.com>, Daniil Gentili <daniil.gentili@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000063cddb06151d6ba2"
From: bukka@php.net (Jakub Zelenka)

--00000000000063cddb06151d6ba2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 2, 2024 at 2:36=E2=80=AFPM Derick Rethans <derick@php.net> wrot=
e:

> On Sat, 30 Mar 2024, Jakub Zelenka wrote:
>
> > On Sat, Mar 30, 2024 at 7:08=E2=80=AFAM Marco Pivetta <ocramius@gmail.c=
om>
> wrote:
> > >
> > > I understand that the XZ project had signed releases too: that still
> > > means that downstream consumers would need to trust the release
> > > managers anyway, and reproduce the whole chain themselves.
> > >
> > > I suppose that's part of OP's concern.
> > >
> > I agree that compromised RM is a problem that we should look into.
> >
> > We have been actually already discussing something similar. I have
> > been thinking about it and it could be potentially used for all
> > builds. The idea is that we would setup worklfow on CI that would run
> > on tag push and it would call (authenticated https request)
> > downloads.php.net server that could do the actual build, sign them and
> > return the hashes to the CI job which would display them and do extra
> > verification (probably its own build to verify that download server
> > work as expected).
>
> ...
>
> > It needs more thinking to iron out all details and make sure it is a
> > secure but I think it would be something worth to look at.
>
> I don't mind coming up with an automated way, but we probably should not
> use the *downloads* server. All it does is serve files. It has no
> compiler or anything else. It's a storage optimised instance with little
> CPU.
>
>
Yeah I agree. I originally thought that it would be good to do it on our
own server so we can possibly sign it there as well but after thinking
about it I rejected that signing idea so there's really no point to do it
on our own server.


> On CI we already test the builds, what does stop us from also just
> having it make the tarball and attach it as an artefact? We can then
> setup somethin gon the downloads server to pull these artefacts. In
> fact, this is exactly what we're already hoping to do for Windows
> downloads too. Having it all in one place is probably even better (and
> easier).
>
> Of course, having CI make the tarballs means we need to trust that CI
> isn't compromised ;-).
>

We will still need RM to sign the build so ideally we should make it
reproducible so RM can verify that CI produced expected build and then sign
it and just upload the signatures (not sure if we actually need signature
uploaded or if they are used just in announcements).

I think this should then prevent compromise of the RM and CI unless CI is
compromised by RM, of course, but that should be very unlikely.

Regards

Jakub

--00000000000063cddb06151d6ba2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Tue, Apr 2, 2024 at 2:36=E2=80=AFPM Derick Reth=
ans &lt;<a href=3D"mailto:derick@php.net">derick@php.net</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 30 Mar 2024=
, Jakub Zelenka wrote:<br>
<br>
&gt; On Sat, Mar 30, 2024 at 7:08=E2=80=AFAM Marco Pivetta &lt;<a href=3D"m=
ailto:ocramius@gmail.com" target=3D"_blank">ocramius@gmail.com</a>&gt; wrot=
e:<br>
&gt; &gt;<br>
&gt; &gt; I understand that the XZ project had signed releases too: that st=
ill <br>
&gt; &gt; means that downstream consumers would need to trust the release <=
br>
&gt; &gt; managers anyway, and reproduce the whole chain themselves.<br>
&gt; &gt;<br>
&gt; &gt; I suppose that&#39;s part of OP&#39;s concern.<br>
&gt; &gt;<br>
&gt; I agree that compromised RM is a problem that we should look into.<br>
&gt; <br>
&gt; We have been actually already discussing something similar. I have <br=
>
&gt; been thinking about it and it could be potentially used for all <br>
&gt; builds. The idea is that we would setup worklfow on CI that would run =
<br>
&gt; on tag push and it would call (authenticated https request) <br>
&gt; <a href=3D"http://downloads.php.net" rel=3D"noreferrer" target=3D"_bla=
nk">downloads.php.net</a> server that could do the actual build, sign them =
and <br>
&gt; return the hashes to the CI job which would display them and do extra =
<br>
&gt; verification (probably its own build to verify that download server <b=
r>
&gt; work as expected).<br>
<br>
...<br>
<br>
&gt; It needs more thinking to iron out all details and make sure it is a <=
br>
&gt; secure but I think it would be something worth to look at.<br>
<br>
I don&#39;t mind coming up with an automated way, but we probably should no=
t <br>
use the *downloads* server. All it does is serve files. It has no <br>
compiler or anything else. It&#39;s a storage optimised instance with littl=
e <br>
CPU.<br>
<br></blockquote><div><br></div><div>Yeah I agree. I originally thought tha=
t it would be good to do it on our own server so we can possibly sign it th=
ere as well but after thinking about it I rejected that signing idea so the=
re&#39;s really no point to do it on our own server.</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
On CI we already test the builds, what does stop us from also just <br>
having it make the tarball and attach it as an artefact? We can then <br>
setup somethin gon the downloads server to pull these artefacts. In <br>
fact, this is exactly what we&#39;re already hoping to do for Windows <br>
downloads too. Having it all in one place is probably even better (and <br>
easier).<br>
<br>
Of course, having CI make the tarballs means we need to trust that CI <br>
isn&#39;t compromised ;-).<br></blockquote><div><br></div><div>We will stil=
l need RM to sign the build so ideally we should make it reproducible so RM=
 can verify that CI produced expected build and then sign it and just uploa=
d the signatures (not sure if we actually need signature uploaded or if the=
y are used just in announcements).</div><div><br></div><div>I think this sh=
ould then prevent compromise of the RM and CI unless CI is compromised by R=
M, of course, but that should be very unlikely.<br></div><div><br></div><di=
v>Regards</div><div><br></div><div>Jakub</div></div></div>

--00000000000063cddb06151d6ba2--