automake
[Top][All Lists]
Advanced

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

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor


From: Bruno Haible
Subject: Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
Date: Fri, 05 Apr 2024 02:04:42 +0200

Richard Stallman commented on Jacob Bachmeyer's idea:
>   > > 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.
> 
> I have a hunch that some effort is needed to do that comparison, but
> that it is feasible to write a script to do it could make it easy.
> Is that so?

Yes, the technical side of such a comparison is relatively easy to
implement:
  - There are less than about 2000 or 5000 *.m4 files that are shared
    between projects. Downloading and storing all historical versions
    of these files will take ca. 0.1 to 1 GB.
  - They would be stored in a content-based index, i.e. indexed by
    sha256 hash code.
  - A distribution could then quickly test whether a *.m4 file found
    in a distrib tarball is "known".

The recurrently time-consuming part is, whenever an "unknown" *.m4 file
appears, to
  - manually review it,
  - update the list of upstream git repositories (e.g. when a project
    has been forked) or the list of releases to consider (e.g. snapshots
    of GNU Autoconf or GNU libtool, or distribution-specific modifications).

I agree with Jacob that a distro can put this in place, without needing
to bother upstream developers.

Bruno






reply via email to

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