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 <mcatanz...@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. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
