Re: checking aclocal m4 files (was: GNU Coding Standards, automake, and the recent xz-utils backdoor)

Jacob Bachmeyer <[email protected]> Tue, 02 Apr 2024 20:32:32 -0500
Newsgroups gmane.comp.sysutils.automake.general,gmane.comp.gnu.standards
Message-ID <[email protected]>
Bruno Haible wrote:
> Jacob Bachmeyer wrote:
>   
>> Another related check that /would/ have caught this attempt would be 
>> comparing the aclocal m4 files in a release against their (meta)upstream 
>> sources before building a package.  This is something distribution 
>> maintainers could do without cooperation from upstream.  If 
>> m4/build-to-host.m4 had been recognized as coming from gnulib and 
>> compared to the copy in gnulib, the nonempty diff would have been 
>> suspicious.
>>     
>
> True.
>
> Note, however, that there would be some false positives:

True; all of these are Free Software, so a non-empty diff would still 
require manual review.

>  libtool.m4 is often shipped modified,
>   a) if the maintainer happens to use /usr/bin/libtoolize and
>      is using a distro that has modified libtool.m4 (such as Gentoo), or
>   

Distribution libtool patches could be accumulated into the set of "known 
sources".

>   b) if the maintainer intentionally improved the support of specific
>      platforms, such as Solaris 11.3.
>   

In this case, the distribution maintainer should ideally take up pushing 
those improvements back to upstream libtool, if they are suitably general.

> Also, for pkg.m4 there is no single upstream source. They distribute
> a pkg.m4.in, from which pkg.m4 is generated on the developer's machine.
>   

This would be a special case, but could be treated as a package-specific 
m4 file anyway, since the developer must generate it.  The developer 
could also write their own m4 macros to use with autoconf.

> But for macros from Gnulib or the Autoconf macros archive, this is a
> reasonable check to make.

This type of check could also allow "sweeping" improvements upstream, in 
the case of a package maintainer that may be unsure of how to upstream 
their changes.  (Of course, upstream needs to be careful about blindly 
collecting improvements, lest some of those "improvements" turn out to 
have come from cracker sockpuppets...)


-- Jacob