GNU bug report logs -
#70114
[PATCH 0/1] Xz backdoor / JiaT75 cleanup for libarchive
Previous Next
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
Message #16 received at 70114 <at> debbugs.gnu.org (full text, mbox):
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 42 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.