[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
- 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/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Eric Gallager, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Tomas Volf, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Russ Allbery, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Eric Gallager, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Peter Johansson, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/03/31
Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Alexandre Oliva, 2024/03/30
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Bob Friesenhahn, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Bruno Haible, 2024/03/31
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor,
Bob Friesenhahn <=
- Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Alfred M. Szmidt, 2024/03/31
Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Alfred M. Szmidt, 2024/03/31
Re: GNU Coding Standards, automake, and the recent xz-utils backdoor, Jacob Bachmeyer, 2024/03/31