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

[Alfred M. Szmidt]

   [[[ 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?

One cannot prvent it, only make it a bit harder -- possibly with the
draw back of making it more harder to find such attacks in the future
but that is hypothetical.

   Someone suggested that configure should not use m4 files that are
   lying around, but rather should fetch them from standard release points,
   WDYT of that idea?

It would be trivial to modify things after it has been fetched, make
the release, and you're back at square one.  One would also need to
keep a list of which m4 files to fetch, people write them for their
packages as well.

Requiring network access to build, or develop a GNU package is also
just a non-starter ... and if it is not requried, well you can just
not use it and again back at square one.


The idea of signing Autoconf offical M4 files is problematic, why
would you trust such a signature?  The attack on xz was performed by
the maintainer, given any rouge maintainer you'r shit ouf of luck.