Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122830
Precedence: bulk
MIME-Version: 1.0
References: <AM8P250MB01705B564C0F9B2F460F56B0E2392@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <9008050F-4EE1-4E19-B513-654602E118A7@benramsey.com> <3d90e236-49d8-4f80-a6dd-3584267a83e3@php.net>
 <586c3320-b38b-47bb-9c06-6762f1eb242b@gmail.com> <cc1e1415-a4cd-4bb2-99f0-e5b05ef6582c@gmail.com>
 <CAEKnhAEMAmgoFmgCPOnV_0sxpaB5SNwRo-qFcE_YeLSduq+bHg@mail.gmail.com> <88decedd-aaf9-43b5-8b65-42d6e1cbf945@gmail.com>
In-Reply-To: <88decedd-aaf9-43b5-8b65-42d6e1cbf945@gmail.com>
Date: Sat, 30 Mar 2024 18:24:43 +0000
Message-ID: <CAEKnhAGm3xZJ_4MEjcQW+60TFSS5GjnppRQ9A9zCe9ehAgktvQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: Daniil Gentili <daniil.gentili@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000007f043d0614e4df8f"
From: bukka@php.net (Jakub Zelenka)

--0000000000007f043d0614e4df8f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sat, Mar 30, 2024 at 3:33=E2=80=AFPM Daniil Gentili <daniil.gentili@gmai=
l.com>
wrote:

> It is also pretty standard thing to distribute configure files (which is
> the file that probably matters most).
>
> The current standard way of distributing generated configure files in
> tarballs is precisely what allowed the xz supply chain attack to go
> unnoticed for so long.
>
>
Do you think it would be different if the change happened in the
distributed source file instead? I mean you could still modify tarball of
the distributed file (e.g. hide somewhere in configure.ac or in our case
more easily in less visible files like various Makefile.frag and similar).
The only thing that you get by using just VCS files is that people could
hash the distributed content of the files and compare it with the hash of
the VCS files but does anyone do this sort of verification?

If you meant using Git archive, then it's not a good idea because it
doesn't have a long term hash stability:
https://github.com/orgs/community/discussions/46034 .


> I strongly believe all projects using autotools, including PHP, should
> switch away from this "standard" way of doing things.
>
> Also don't forget that we need to also provide Windows builds which are
> binaries so we need some sort of verification of this type in any case.
>
> Of course, build reproducibility is a very good thing, but when a user
> downloads a binary, they're aware that they're getting a compiled blob
> which might contain injected malicious code (especially if there's no bui=
ld
> reproducibility); when a user downloads a source tarball, there's a false
> sense of security rooted in the mistaken belief that the source code in t=
he
> tarball matches the one distributed in the VCS, but in reality, the tarba=
ll
> also contains potentially malicious semi-compiled blobs, not present in t=
he
> VCS.
>
>
> It would require compromising the CI as well as the download serves
> happening at the same time which seems to me like an impossible scenario.
>
> I misunderstood your original message, I thought you meant that there
> would be some new CI system hosted on downloads.php.net dedicated to
> verifying, not the current GHA CI system, which is configured on the publ=
ic
> VCS.
>
> If GHA is used for verifying builds, that would make more sense, but then
> users would be required to check the status of a github pipeline to
> validate that the tarball was not compromised (or alternatively clone fro=
m
> source and re-generate the build scripts manually, or simply trust the
> release manager, which brings us to square 1).
>

As noted above, you would need to do much more involved verification if
only generated source codes were removed. With GHA it would be just failed
build and we could integrate notification (e.g. to Foundation Slack) so
more people could be easily aware if there is such problem.

Regards

Jakub

--0000000000007f043d0614e4df8f
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 Sat, Mar 30, 2024 at 3:33=E2=80=AFPM Daniil Gen=
tili &lt;<a href=3D"mailto:daniil.gentili@gmail.com">daniil.gentili@gmail.c=
om</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>It is also pretty standard thing to distribute configure
            files (which is the file that probably matters most).</div>
        </div>
      </div>
    </blockquote>
    <p>The current standard way of distributing generated configure
      files in tarballs is precisely what allowed the xz supply chain
      attack to go unnoticed for so long.</p>
    <p></p></div></blockquote><div><br></div><div>Do you think it would be =
different if the change happened in the distributed source file instead? I =
mean you could still modify tarball of the distributed file (e.g. hide some=
where in <a href=3D"http://configure.ac">configure.ac</a> or in our case mo=
re easily in less visible files like various Makefile.frag and similar). Th=
e only thing that you get by using just VCS files is that people could hash=
 the distributed content of the files and compare it with the hash of the V=
CS files but does anyone do this sort of verification?</div><div><br></div>=
<div>If you meant using Git archive, then it&#39;s not a good idea because =
it doesn&#39;t have a long term hash stability:=C2=A0<a href=3D"https://git=
hub.com/orgs/community/discussions/46034">https://github.com/orgs/community=
/discussions/46034</a> .=C2=A0</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div><p>I strongly believe all projects using a=
utotools, including PHP,
      should switch away from this &quot;standard&quot; way of doing things=
.<br>
      <br>
    </p>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div> Also don&#39;t forget that we need to also provide Windows
            builds which are binaries so we need some sort of
            verification of this type in any case. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Of course, build reproducibility is a very good thing, but when a
      user downloads a binary, they&#39;re aware that they&#39;re getting a
      compiled blob which might contain injected malicious code
      (especially if there&#39;s no build reproducibility); when a user
      downloads a source tarball, there&#39;s a false sense of security
      rooted in the mistaken belief that the source code in the tarball
      matches the one distributed in the VCS, but in reality, the
      tarball also contains potentially malicious semi-compiled blobs,
      not present in the VCS.<br>
    </p>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>=C2=A0</div>
          <div>It would require compromising the CI as well as the
            download serves happening at the same time which seems to me
            like an impossible scenario.</div>
          <br>
        </div>
      </div>
    </blockquote>
    <p>I misunderstood your original message, I thought you meant that
      there would be some new CI system hosted on <a href=3D"http://downloa=
ds.php.net" target=3D"_blank">downloads.php.net</a>
      dedicated to verifying, not the current GHA CI system, which is
      configured on the public VCS.</p>
    <p>If GHA is used for verifying builds, that would make more sense,
      but then users would be required to check the status of a github
      pipeline to validate that the tarball was not compromised (or
      alternatively clone from source and re-generate the build scripts
      manually, or simply trust the release manager, which brings us to
      square 1).</p></div></blockquote><div><br></div><div>As noted above, =
you would need to do much more involved verification if only generated sour=
ce codes were removed. With GHA it would be just failed build and we could =
integrate notification (e.g. to Foundation Slack) so more people could be e=
asily aware if there is such problem.</div><div><br></div><div>Regards</div=
><div><br></div><div>Jakub</div></div></div>

--0000000000007f043d0614e4df8f--