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. Zbyszek -- _______________________________________________ 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
