Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122842
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>
 <1c7bcd0e-4e32-480f-acd2-2c8eb049bde2@gmail.com> <3E13B046-FE40-48D7-AAF0-13362B12C438@cschneid.com>
 <CAPzBOBNxnvbTZDTj1WRp_sduKFQB+mbcz2RfAvpO1DEciaYY4g@mail.gmail.com> <8AD52323-A273-40FE-90FD-8A7AE55535AE@benramsey.com>
In-Reply-To: <8AD52323-A273-40FE-90FD-8A7AE55535AE@benramsey.com>
Date: Mon, 1 Apr 2024 10:01:10 +0200
Message-ID: <CAPzBOBN=wM7wqhbm3JPXQ3V3XgnT1dRdruLvcgoqJwObrpxTUw@mail.gmail.com>
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: Ben Ramsey <ben@benramsey.com>
Cc: Christian Schneider <cschneid@cschneid.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Mon, Apr 1, 2024 at 1:53=E2=80=AFAM Ben Ramsey <ben@benramsey.com> wrote=
:
>
> > On Mar 31, 2024, at 11:08, Robert Landers <landers.robert@gmail.com> wr=
ote:
> >
> > There are probably multiple parties that require trust: the people
> > hosting the CI servers, the people with access to the CI servers, the
> > RM, and maybe more that I can't think of right now.
> >
> > One option would be to have
> >
> > - CI push the code + generated files to a git-branch `php-8.3-built`
> > (or something) so that changes can be reviewed, along with the
> > tarball.
> > - CI signs the commit and tarball.
> > - RM checks out commit and, also signs the tarball, then does a git
> > commit --amend --signoff and "blesses" the commit
> > - RM releases tarball
>
>
> When I was considering this and created a PR that followed these steps, I=
 discussed the process with folks from other open source communities, notab=
ly the Apache Software Foundation community, since some of their projects f=
ollow similar processes. The notion of automating the build and signing it =
on a remote machine, only to be inspected and signed again on the release m=
anager=E2=80=99s machine was outright rejected by everyone. The machine whe=
re it is signed by the RM should be the machine where it is built, accordin=
g to everyone I spoke with.
>
> As it stands right now, if we build the tarball on a remote machine (in C=
I), and then the RM wants to compare it and build it locally, the hashes on=
 those tarballs will be different because we can=E2=80=99t guarantee reprod=
ucible builds. If we could guarantee reproducible builds, then maybe this p=
rocess could work, but it would still require the RM to build it locally fr=
om the source tag in order to trust and verify that nothing sneaked in on t=
he CI machine.
>
> Cheers,
> Ben
>

I think the big point is to store the generated files in git for CI
builds. To verify the tarball is that commit, checkout the branch and
untar the file, there should be no changes, git clean should result in
no removed files, etc. This would make injecting malicious code
visible, at the very least. Whether someone catches it and actually
reviews the generated files is a different question. But if we wanted
something that is better than nothing... it's a pretty simple
solution.

Reproducible builds is an orthogonal but related problem.