guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Kehayias
Subject: [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@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.
>

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]