On Wed, Apr 03, 2024 at 12:47:39AM +0200, Kevin Kofler via devel wrote: > Richard W.M. Jones wrote: > > Yes, in this case the attacker had set the serial number to 30, but > > the latest upstream serial number was 3. autoreconf won't replace the > > file in this case unless it is deleted. There really should be an > > "always replace if you can" option in autoreconf. > > Is that not what -f is supposed to do? At least, the documentation claims > so, but the implementation does not actually do what is documented. The upstream autoconf discussion says that 'autoreconf -fi' behavior on which 'serial NN' .m4 files to update is determined by automake, not autoconf, in part inspired by semantics desired in gnulib. And the automake and gnulib developers have argued that the upstream behavior is intentional: https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg00005.html So the only sane way to work around the upstream behavior (if we insist that working around it is essential, such as if we insist on running autoreconf in order to pull in modernized config.guess that will allow us to build on more platforms than were present at the time the upstream package was cut), is to do something like removing all .m4 files, then autoreconf -fi to reinstall all of them with known versions of the same .m4 files that we somehow curate as being more reliable than the ones that upstream tested their release tarball with. Lots of busy work, but if we think it will help as another layer of reassurance to keep our customers happy, then we can sign up for it. However, although it is unlikely that upstream automake will accept a patch to change the existing 'autoreconf -fi' behavior of not overriding an already-present .m4 with a higher serial, getting some other patch in that adds a new option such as 'autoreconf --ignore-serial -fi' might be possible. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
