bug-standards
[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: Bob Friesenhahn
Subject: Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
Date: Sun, 31 Mar 2024 09:45:38 -0500
User-agent: Mozilla Thunderbird

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




reply via email to

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