GNU bug report logs - #70113
[PATCH 1/1] gnu: libarchive: Fix a potential security issue.

Previous Next

Full log

Message #32 received at 70113 <at> debbugs.gnu.org (full text, mbox):

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

Hello,

On Tue, Apr 02, 2024 at 03:45 PM, pelzflorian (Florian Pelz) wrote:

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

Well, it removes one step where something can be added. From what I
understand release tarballs don't match a git checkout as often build
artifacts (from autotools) are added, so it is just another potential
attack vector. Indeed, it was only part of the attack here, but I do
believe there is general support for trying to favor git checkouts
when we can (there is overhead and I think issues for parts in
bootstrapping, to get git). Certainly not perfect, but gets us to
"just" the source. One can still do things with access of course.

Thanks Leo for the quick work here and pushing the patch, much
appreciated!

John

Previous Next

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