On Sat, 2024-03-30 at 15:23 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
Once upon a time, Michael Catanzaro mcatanzaro@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.
I do not know if this changed in the last couple of years, but tarballs in github are not stable (or weren't up to a couple years ago), they are cached for a period of time, so they may look stable in busy projects where you have regular downloads that keep the cache alive, but they are *regenerated* from the tag for seldom downloaded tarballs. And when that happens then hashes change.
Simo.