On Sun, Mar 31, 2024 at 5:26 PM Christian Schneider <cschn...@cschneid.com> wrote: > > Am 30.03.2024 um 16:35 schrieb Daniil Gentili <daniil.gent...@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
