Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122827
Content-Type: multipart/alternative;
 boundary="------------g8XPHx7PzDoY74ZS93OpVAzE"
Message-ID: <88decedd-aaf9-43b5-8b65-42d6e1cbf945@gmail.com>
Date: Sat, 30 Mar 2024 16:31:02 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: internals@lists.php.net
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>
Content-Language: en-US
In-Reply-To: <CAEKnhAEMAmgoFmgCPOnV_0sxpaB5SNwRo-qFcE_YeLSduq+bHg@mail.gmail.com>
From: daniil.gentili@gmail.com (Daniil Gentili)

This is a multi-part message in MIME format.
--------------g8XPHx7PzDoY74ZS93OpVAzE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,
> 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.

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 
build 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 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.

> 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 
public 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 
from source and re-generate the build scripts manually, or simply trust 
the release manager, which brings us to square 1).


Regards,

Daniil Gentili.

--------------g8XPHx7PzDoY74ZS93OpVAzE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hi,<br>
    <blockquote type="cite"
cite="mid:CAEKnhAEMAmgoFmgCPOnV_0sxpaB5SNwRo-qFcE_YeLSduq+bHg@mail.gmail.com">
      <div dir="ltr">
        <div class="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>I strongly believe all projects using autotools, including PHP,
      should switch away from this "standard" way of doing things.<br>
      <br>
    </p>
    <blockquote type="cite"
cite="mid:CAEKnhAEMAmgoFmgCPOnV_0sxpaB5SNwRo-qFcE_YeLSduq+bHg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> 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. <br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>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 build 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 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="cite"
cite="mid:CAEKnhAEMAmgoFmgCPOnV_0sxpaB5SNwRo-qFcE_YeLSduq+bHg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> </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 downloads.php.net
      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>
    <p><br>
    </p>
    <p>Regards,</p>
    <p>Daniil Gentili.<br>
    </p>
  </body>
</html>

--------------g8XPHx7PzDoY74ZS93OpVAzE--