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

From: Efraim Flashner <[email-masked]>
Date: Tue, 2 Apr 2024 16:24:04 +0300

On Tue, Apr 02, 2024 at 03:23:44AM +0000, John Kehayias via Guix-patches via wrote:
> Hi Leo,
> 
> On Sun, Mar 31, 2024 at 04:44 PM, Leo Famulari wrote:
> 
> > https://github.com/libarchive/libarchive/pull/2101
> >
> > * gnu/packages/backup.scm (libarchive)[replacement]: New field.
> > (libarchive/fixed): New variable.
> > * gnu/packages/patches/libarchive-remove-potential-backdoor.patch: New file.
> > * gnu/local.mk (dist_patch_DATA): Add it.
> >
> 
> Overall changes look good, but I have not had a chance to try it locally
> (building or dependents).
> 

This looks like what I was going to suggest

> [...]
> 
> > +(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.

In this case it was just the patch which didn't do (just) what the
commit message said. IMO applying this patch will make us safe from this
potential JiaT75 backdoor, no bootstrapping from source needed.

> I haven't had a chance to look at potential ABI changes, but perhaps at
> least v3.6.2 is graftable? That also lists a security update (as well as
> later versions).
> 
> Or, if it is easier and this is tested on your end, let's push this and
> do an upgrade to the latest on a branch. I would volunteer mesa-updates,
> but Cuirass has been stuck all day not building anything, so I don't
> know what will end up being quickest (which branch or a new one).

If it turns out that we need to move forward a bit to guard against
other CVEs then this patch should be forward compatible, considering it
was just added to the libarchive repository.

> Thanks for the quick work!
> John

Indeed. Thanks!

-- 
Efraim Flashner   <[email-masked]>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted