automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: checking aclocal m4 files (was: GNU Coding Standards, automake, and


From: Jacob Bachmeyer
Subject: Re: checking aclocal m4 files (was: GNU Coding Standards, automake, and the recent xz-utils backdoor)
Date: Tue, 02 Apr 2024 20:32:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]