[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
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, (continued)
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Russ Allbery, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Eric Gallager, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Bruno Haible, 2024/04/02
- Re: checking aclocal m4 files (was: GNU Coding Standards, automake, and the recent xz-utils backdoor), Jacob Bachmeyer, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Richard Stallman, 2024/04/04
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor,
Bruno Haible <=
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Sam James, 2024/04/05
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Richard Stallman, 2024/04/08
- Re: detecting modified m4 files (was: GNU Coding Standards, automake, and the recent xz-utils backdoor), Jacob Bachmeyer, 2024/04/07
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Richard Stallman, 2024/04/04
Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/04/02
Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Richard Stallman, 2024/04/01
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/04/02
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Richard Stallman, 2024/04/04
- Re: GCC reporting piped input as a security feature (was: GNU Coding Standards, automake, and the recent xz-utils backdoor), Jacob Bachmeyer, 2024/04/06
- Re: GCC reporting piped input as a security feature (was: GNU Coding Standards, automake, and the recent xz-utils backdoor), Richard Stallman, 2024/04/08