Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122888
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> <CAEKnhAG4AYy9wPzuVq3y_hqfjcWMDi8HtCkVQyL9Txoqogwz7A@mail.gmail.com>
 <CAO__Xv7=31W8FQgJ8xTokzA_qu0wo0bcVfOC7dKTMGGeOxmAhA@mail.gmail.com>
 <CAEKnhAEtuiQZ_7TpkwcONCeJ4=nOB-_UCHoJ+ojO1tGVNCmcWw@mail.gmail.com> <ef7edce7-8787-4eb0-8fba-254168e1d266@gmail.com>
In-Reply-To: <ef7edce7-8787-4eb0-8fba-254168e1d266@gmail.com>
Date: Tue, 2 Apr 2024 18:28:30 +0000
Message-ID: <CAEKnhAHaUwXt7Lekxp6DYO-Q1pPEwOdcEA2XAhD8HdoAVBnb-A@mail.gmail.com>
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000080647c061521466e"
From: bukka@php.net (Jakub Zelenka)

--00000000000080647c061521466e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 2, 2024 at 7:14=E2=80=AFPM Stanislav Malyshev <smalyshev@gmail.=
com>
wrote:

> Hi!
>
> That is something PHP is missing atm, no one can verify the build process
>> for releases.
>>
>
> Yes that's what I was suggesting. This should be done by RM. In that way,
> the RM becomes more someone that verifies the build and not the actual
> person that provides the build.
>
> I'm not sure though how the RM can really verify it. I mean, we have the
> tar blob that comes from the git repo - which we assume is legit. We also
> have some files that aren't in the repo. If RM builds them by themselves
> then the question comes up what if RM's environment is compromised and
> something bad is injected. If RM receives the files from outside source,
> how the RM verifies they are genuine?  I don't think reading through the
> whole "configure" file and verifying it's not bad is realistic for any
> person. And from what I understand, "configure" and such are quite
> environment-dependant, so you can't just have a standard hash to compare
> to. You can't have the RM to just run "buildconf" again and do hash check
> because they may get different bits than the ones coming from the outside=
,
> like CI. I dunno, maybe if we had some kind of Docker image for generatin=
g
> it that would produce reproducible result, that'd be possible? Otherwise =
I
> am still not sure how the verification procedure looks like.
>

Yeah as I already noted that it needs to be reproducible so the RM would
need to have exactly the same version of all build tools as used in CI. I
think the only option would be to use Docker image for that. We could then
use the same image in CI (job container). In such way we should be able to
implement the same process (there might some extra bits to do but I think
it should be doable in general). We could potentially store the produced
hashes to some CI artifact and possibly also make it available from the
downloads server (once downloaded from CI) so the RM could have a script
that just automatically compare all hashes. So the ideal scenario would be
that RM just runs a command that will do all for them.


> Right now as I understand we're simply trusting the RM that they have
> uncompromised environment and third parties have no way to verify it's th=
e
> case. But I guess it's time we do better?
>

Yes exactly that. Currently the RM can change the build as they want so if
they are compromised, then we might have the same issue that happened to XZ=
.

Regards

Jakub

--00000000000080647c061521466e
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 7:14=E2=80=AFPM Stanislav M=
alyshev &lt;<a href=3D"mailto:smalyshev@gmail.com">smalyshev@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></=
u>

 =20
   =20
 =20
  <div>
    <p>Hi!<br>
    </p>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div dir=3D"ltr">
              <div class=3D"gmail_quote">
                <div>That is something PHP is missing atm, no one can
                  verify the build process for releases.<br>
                </div>
              </div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Yes that&#39;s what I was suggesting. This should be done by
            RM. In that way, the RM becomes more someone that verifies
            the build and not the actual person that provides the build.</d=
iv>
        </div>
      </div>
    </blockquote>
    <p>I&#39;m not sure though how the RM can really verify it. I mean, we
      have the tar blob that comes from the git repo - which we assume
      is legit. We also have some files that aren&#39;t in the repo. If RM
      builds them by themselves then the question comes up what if RM&#39;s
      environment is compromised and something bad is injected. If RM
      receives the files from outside source, how the RM verifies they
      are genuine?=C2=A0 I don&#39;t think reading through the whole &quot;=
configure&quot;
      file and verifying it&#39;s not bad is realistic for any person. And
      from what I understand, &quot;configure&quot; and such are quite
      environment-dependant, so you can&#39;t just have a standard hash to
      compare to. You can&#39;t have the RM to just run &quot;buildconf&quo=
t; again
      and do hash check because they may get different bits than the
      ones coming from the outside, like CI. I dunno, maybe if we had
      some kind of Docker image for generating it that would produce
      reproducible result, that&#39;d be possible? Otherwise I am still not
      sure how the verification procedure looks like.</p></div></blockquote=
><div><br></div><div>Yeah as I already noted that it needs to be reproducib=
le so the RM would need to have exactly the same version of all build tools=
 as used in CI. I think the only option would be to use Docker image for th=
at. We could then use the same image in CI (job container). In such way we =
should be able to implement the same process (there might some extra bits t=
o do but I think it should be doable in general). We could potentially stor=
e the produced hashes to some CI artifact and possibly also make it availab=
le from the downloads server (once downloaded from CI) so the RM could have=
 a script that just automatically compare all hashes. So the ideal scenario=
 would be that RM just runs a command that will do all for them.</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"><div>
    <p>Right now as I understand we&#39;re simply trusting the RM that they
      have uncompromised environment and third parties have no way to
      verify it&#39;s the case. But I guess it&#39;s time we do better?</p>=
</div></blockquote><div><br></div><div>Yes exactly that. Currently the RM c=
an change the build as they want so if they are compromised, then we might =
have the same issue that happened to XZ.</div><div><br></div><div>Regards</=
div><div><br></div><div>Jakub</div><div><br></div><div><br></div></div></di=
v>

--00000000000080647c061521466e--