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.
