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

> I think it is pretty clear by now. [1][2][3]
>
> [1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
> [2] https://news.ycombinator.com/item?id=39865810
> [3] https://www.youtube.com/watch?v=Kw8MCN5uJPg

There is not much one can do when a maintainer with signing/release 
power does something intentionally wrong.

My GraphicsMagick oss-fuzz builds include xz and are still working (but 
with a few security issues open due to problems in xz). The URL used is 
https://github.com/xz-mirror/xz. When I visit that URL, I see this 
message "This repository has been archived by the owner on Aug 28, 2023. 
It is now read-only.", so it seems that this is a stale repository.  The 
upstream repository to it has been disabled.

Regardless, how can Autotool's based projects be more assured of 
security given how they are selectively assembled from "parts"? I have 
already been concerned about using any Autotools packages provided by 
the operating system, since they are likely dated, but may also have 
been modified by the distribution package maintainers.

Besides GNU Autoconf, Automake, and libtool, there are also several 
popular Autoconf macro archives. Sometimes components are automatically 
downloaded via build scripts. This is not at all a "safe" situation. 
There is quite a lot of trust, which may be unwarranted.

Should the GNU project itself perform an independent file verification 
of included Autotools files (Autoconf .m4 files, scripts, libtool, etc.) 
for all of the packages it distributes? Besides verifying the original 
files which are re-distributed, it might be necessary to verify that 
generated files are correct, and are in fact based on the files which 
are re-distributed.

Bob

-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt