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

[Bob Friesenhahn]

On 4/2/24 16:42, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    > My first thought was that Autoconf is a relatively trivial attack vector
>    > since it is so complex and the syntax used for some parts (e.g. m4 and
>    > shell scripts) is so arcane.  In particular, it is common for Autotools
>    > stuff to be installed on a computer (e.g. by installing a package from
>    > an OS package manager) and then used while building.  For example, there
>    > are large collections of ".m4" files installed.  If one of the m4 files
>    > consumed has been modified, then the resulting configure script has been
>    > modified.
>
> Can anyone think of a feasible way to prevent this sort of attack?
A common way would be to use PGP signing to bless a set of files. 
Perhaps a manifest which specifies the file names/paths and their sha256 
would be sufficient.  But there needs to be a way to augment this in 
case there are multiple collections of blessed files, including those 
blessed by the user.
>    > It may be that an OS package manager
>
> What is an "OS package manager"?

A popular OS package manager is Debian 'apt'. Well designed ones provide 
a way to test if installed files on the system have been modified.

But I only use this as an example since I don't think that any GNU build 
system should depend on something specific to an operating system.

> Could you say concretely what this would do?  Which files do you have
> in mind?  The m4 files discussed above?

M4 files, scripts, templates, and any other standard files which may be 
assimilated as part of the build process.

>    > If installed files were themselves independently signed (or sha256s of
>    > the files are contained in a signed manifest), and Autotools was able to
>    > validate them while copying into a project ("bootstrapping"), then at
>    > least there is some assurance that the many files which were consumed
>    > have not been subverted.
>
> Is this a proposal to deal with the problem described above?  I think
> maybe it is, but things are not concrete enough for me to tell for
> certain.

I do not think that it would solve the specific issues which lead to the 
xz-utils backdoor, but it may solve a large class of issues which have 
been ignored up until now.  People preparing operating system 
distributions solve such issues via the extensive (and repeatable) 
processes that they use.

GNU software developers are less likely (or able) to solve issues via 
extensive processes.  They expect that 'make distcheck' will prepare a 
clean distribution tarball.

Bob

--

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt