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

[pelzflorian (Florian Pelz)]

Hello,

John Kehayias via Guix-patches via <guix-patches@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@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