Re: Consider removing autogenerated files from tarballs

On Sun, Mar 31, 2024 at 5:26 PM Christian Schneider <cschneid@cschneid.com> wrote: > > Am 30.03.2024 um 16:35 schrieb Daniil Gentili <daniil.gentili@gmail.com>: > >> That would break lots of tools as it requires extra dependencies so it is not > >> something that would could in stable versions. > > Btw, I do not believe that "it would require end users to install autotools and bison > > in order to compile PHP from tarballs" is valid reason to delay the patching of a serious > > attack vector ASAP. > > I agree with Jakub that removing configure would just shift the problem, not solve it, while at > the same time puts a new burden on people compiling PHP from downloaded archives. > > But my main question is: I fail to see the difference whether I plant my malicious code in > configure, configure.ac or *.c: Someone has to review the changes and notice the problem. And we > have to trust the RMs. What am I missing? > > Regards, > - Chris 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