GNU bug report logs - #70114
[PATCH 0/1] Xz backdoor / JiaT75 cleanup for libarchive

Previous Next

Package: guix-patches;

Reported by: Leo Famulari <leo <at> famulari.name>

Date: Sun, 31 Mar 2024 20:50:02 UTC

Severity: normal

Tags: patch, security

Merged with 70113

Done: Leo Famulari <leo <at> famulari.name>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: John Kehayias <john.kehayias <at> protonmail.com>
Cc: 70114 <at> debbugs.gnu.org, 70113 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: [bug#70114] [bug#70113] [PATCH 1/1] gnu: libarchive: Fix a potential security issue.
Date: Tue, 02 Apr 2024 15:45:51 +0200
Hello,

John Kehayias via Guix-patches via <guix-patches <at> gnu.org> writes:
>> +(define-public libarchive/fixed
>> +  (package
>> +    (inherit libarchive)
>> +    (version "3.6.1")
>> +    (source
>> +     (origin
>> +       (method url-fetch)
>> +       (uri (list (string-append "https://libarchive.org/downloads/libarchive-"
>> +                                 version ".tar.xz")
>> +                  (string-append "https://github.com/libarchive/libarchive"
>> +                                 "/releases/download/v" version "/libarchive-"
>> +                                 version ".tar.xz")))
>
> In light of the xz backdoor, perhaps we should just do a git checkout of
> the v3.6.1 tag rather than the tarballs? Assuming that works, of course.

Not having followed the details, I believe the git checkout contained an
incomplete part of the malicious code too, from what Joshua Branson (I
guess the sender is him?) cites from Phoronix
<https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00002.html>:

jbranso <at> dismail.de writes:
> The malicious injection present in the xz versions 5.6.0 and 5.6.1
> libraries is obfuscated and only included in full in the download package
> - the Git distribution lacks the M4 macro that triggers the build 
> of the malicious code. The second-stage artifacts are present in 
> the Git repository for the injection during the build time, in 
> case the malicious M4 macro is present.

It doesn’t look like avoiding tarballs gives us more verified code.

Regards,
Florian




This bug report was last modified 1 year and 41 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.