Hi, On Sat, Mar 30, 2024 at 3:33 PM Daniil Gentili <daniil.gent...@gmail.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 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). > 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
