On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
Once upon a time, Michael Catanzaro <mcatanzaro(a)redhat.com>
said:
> I agree that running autoreconf on our packages makes sense to start
> doing. Still, to avoid this backdoored m4 file, we would have needed
> to stop using release tarballs altogether and switch to using git
> tags directly instead. That would at least force the malicious
> attacker to commit their code to version control, making it slightly
> harder to hide the attack.
Using a signed tarball is ideally better than a git tag (it's an extra
level of author attestation)... but where both are available, it'd be
nice to have a way to denote in the spec file that there are two URLs
for the source. In this case, if both URLs were listed and something
could be run to automatically fetch and compare them, the attack code
would have been flagged.
Tarball production should be reproducible. Then the maintainer can
both make a signature locally and make it public, and users can download
the auto-generated tarball.
In fact, github tarball generation is stable. A few years ago they tried
to improve the compression method (i.e. .tar would be still identical,
but .tar.gz would be different), and after a huge outcry this was reverted.
They still haven't officially said that it's stable, but let's hope that
it never changes, at least not without a suitable advance warning.
Zbyszek