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

2024-04-02 Thread Eric Blake
[adding in coreutils, for some history] On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote: > I was recently reading about the backdoor announced in xz-utils the > other day, and one of the things that caught my attention was how > (ab)use of the GNU build system played a role in allowi

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

2024-04-02 Thread Karl Berry
I'm also wondering whether the GNU system should recommend using zstd instead of or in addition to xz for compression purposes. I'm not sure GNU explicitly recommends anything. Although the tarball examples in standards.texi and maintain.texi all use gz, I don't think even gz is explicitly

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

2024-04-02 Thread Bob Friesenhahn
I'm also wondering whether the GNU system should recommend using zstd instead of or in addition to xz for compression purposes. Automake gained support for dist-zstd back in 2019 [1], but I'm not sure how many projects are using it yet. [1] https://git.savannah.gnu.org/cgit/automake.git/commit/?

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

2024-04-02 Thread Jeffrey Walton
On Tue, Apr 2, 2024 at 6:05 PM Karl Berry wrote: > > I'm also wondering whether the GNU system should recommend using zstd > instead of or in addition to xz for compression purposes. > > I'm not sure GNU explicitly recommends anything. Although the tarball > examples in standards.texi and

Re: compressed release distribution formats (was: GNU Coding Standards, automake, and the recent xz-utils backdoor)

2024-04-02 Thread Jacob Bachmeyer
Eric Blake wrote: [adding in coreutils, for some history] [...] At any rate, it is now obvious (in hindsight) that zstd has a much larger development team than xz, which may alter the ability of zstd being backdoored in the same way that xz was, merely by social engineering of a lone maintainer