Re: autoreconf --force seemingly does not forcibly update everything

Hi!

On Mon, 2024-04-01 at 12:43:02 -0500, Eric Blake wrote:
> Widening the audience to include bug-gnulib, which is the upstream
> source of "# build-to-host.m4 serial 3" which was bypassed by the
> malicious "# build-to-host.m4 serial 30".
> 
> On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote:
> > While analyzing the recent xz backdoor hook into the build system [A],
> > I noticed that one of the aspects why the hook worked was because it
> > seems like «autoreconf -f -i» (that is run in Debian as part of
> > dh-autoreconf via dh) still seems to take the serial into account,
> > which was bumped in the tampered .m4 file. If either the gettext.m4
> > had gotten downgraded (to the version currently in Debian, which would
> > not have pulled the tampered build-to-host.m4), or once Debian upgrades
> > gettext, the build-to-host.m4 would get downgraded to the upstream
> > clean version, then the hook would have been disabled and the backdoor
> > would be inert. (Of course at that point the malicious actor would
> > have found another way to hook into the build system, but the less
> > avenues there are the better.)
> > 
> > I've tried to search the list and checked for old bug reports on the
> > debbugs.gnu.org site, but didn't notice anything. To me this looks like
> > a very unexpected behavior, but it's not clear whether this is intentional
> > or a bug. In any case regardless of either position, it would be good to
> > improve this (either by fixing --force to force things even if
> > downgrading, or otherwise perhaps to add a new option to really force
> > everything).
> > 
> > [A] <https://lists.debian.org/debian-devel/2024/03/msg00367.html>
> >     Longish mail, search for "try to go in detail" for the analysis.
> 
> My understanding is that the use of serial numbers in .m4 snippets was
> intentional in gnulib (more or less where the practice originated),
> but only because gnulib prefers a linear history (everything is
> monotonically increasing, no forks for the serial number to diverge
> on).  In light of this weekend's mess, Bruno may have more ideas about
> how to prevent his files from being turned into backdoor delivery
> mechanisms in the future.

I think the serial numbers and the non-downgrade behavior makes sense
in general in non-force mode, but I still expect and I find it very
surprising that --force does not overwrite everything, when that seems
like what's been asked.

Of course the problem then becomes, how much might might now break if
--force would truly force a refresh from system files, because I'm
assuming this has been the behavior all along?

At least in Debian I guess we could perform a mass rebuild with a
modified autoreconf that truly forces to see how much breaks. But even
if much breaks, I think that fallout is something we might want to fix
anyway, but perhaps in a controlled/staged way.

Thanks,
Guillem