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
