Report forwarded
to guix-patches@gnu.org: bug#70113; Package guix-patches.
(Sun, 31 Mar 2024 20:50:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Leo Famulari <leo@famulari.name>:
New bug report received and forwarded. Copy sent to guix-patches@gnu.org.
(Sun, 31 Mar 2024 20:50:02 GMT) (full text, mbox, link).
Subject: [PATCH 1/1] gnu: libarchive: Fix a potential security issue.
Date: Sun, 31 Mar 2024 16:44:51 -0400
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.
Change-Id: I939e9b842b10d1a78125da4a4599c38d9c037079
---
gnu/local.mk | 1 +
gnu/packages/backup.scm | 19 ++++++++
...libarchive-remove-potential-backdoor.patch | 47 +++++++++++++++++++
3 files changed, 67 insertions(+)
create mode 100644 gnu/packages/patches/libarchive-remove-potential-backdoor.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index f2b480bded..68c6851402 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1575,6 +1575,7 @@ dist_patch_DATA = \
%D%/packages/patches/liba52-use-mtune-not-mcpu.patch \
%D%/packages/patches/libaio-32bit-test.patch \
%D%/packages/patches/libaio-riscv-test5.patch \
+ %D%/packages/patches/libarchive-remove-potential-backdoor.patch \
%D%/packages/patches/libbase-fix-includes.patch \
%D%/packages/patches/libbase-use-own-logging.patch \
%D%/packages/patches/libbonobo-activation-test-race.patch \
diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 604102bc7b..5dfdfe7dd4 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -259,6 +259,7 @@ (define-public hdup
(define-public libarchive
(package
(name "libarchive")
+ (replacement libarchive/fixed)
(version "3.6.1")
(source
(origin
@@ -347,6 +348,24 @@ (define-public libarchive
@command{bsdcat}, @command{bsdcpio} and @command{bsdtar} commands.")
(license license:bsd-2)))
+(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")))
+ (patches (search-patches "libarchive-remove-potential-backdoor.patch"))
+ (sha256
+ (base32
+ "1rj8q5v26lxxr8x4b4nqbrj7p06qvl91hb8cdxi3xx3qp771lhas"))))))
+
+
(define-public rdup
(package
(name "rdup")
diff --git a/gnu/packages/patches/libarchive-remove-potential-backdoor.patch b/gnu/packages/patches/libarchive-remove-potential-backdoor.patch
new file mode 100644
index 0000000000..2b9a9e2ffe
--- /dev/null
+++ b/gnu/packages/patches/libarchive-remove-potential-backdoor.patch
@@ -0,0 +1,47 @@
+Remove code added by 'JiaT75', the malicious actor that backdoored `xz`:
+
+https://github.com/libarchive/libarchive/pull/2101
+
+At libarchive, they are reviewing all code contributed by this actor:
+
+https://github.com/libarchive/libarchive/issues/2103
+
+See the original disclosure and subsequent discussion for more
+information about this incident:
+
+https://seclists.org/oss-sec/2024/q1/268
+
+Patch copied from upstream source repository:
+
+https://github.com/libarchive/libarchive/pull/2101/commits/e200fd8abfb4cf895a1cab4d89b67e6eefe83942
+
+From 6110e9c82d8ba830c3440f36b990483ceaaea52c Mon Sep 17 00:00:00 2001
+From: Ed Maste <emaste@freebsd.org>
+Date: Fri, 29 Mar 2024 18:02:06 -0400
+Subject: [PATCH] tar: make error reporting more robust and use correct errno
+ (#2101)
+
+As discussed in #1609.
+---
+ tar/read.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/tar/read.c b/tar/read.c
+index af3d3f42..a7f14a07 100644
+--- a/tar/read.c
++++ b/tar/read.c
+@@ -371,8 +371,9 @@ read_archive(struct bsdtar *bsdtar, char mode, struct archive *writer)
+ if (r != ARCHIVE_OK) {
+ if (!bsdtar->verbose)
+ safe_fprintf(stderr, "%s", archive_entry_pathname(entry));
+- fprintf(stderr, ": %s: ", archive_error_string(a));
+- fprintf(stderr, "%s", strerror(errno));
++ safe_fprintf(stderr, ": %s: %s",
++ archive_error_string(a),
++ strerror(archive_errno(a)));
+ if (!bsdtar->verbose)
+ fprintf(stderr, "\n");
+ bsdtar->return_value = 1;
+--
+2.41.0
+
--
2.41.0
Merged 7011370114.
Request was from Leo Famulari <leo@famulari.name>
to control@debbugs.gnu.org.
(Sun, 31 Mar 2024 20:51:03 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#70113; Package guix-patches.
(Sun, 31 Mar 2024 20:52:02 GMT) (full text, mbox, link).
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).
[...]
> +(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.
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).
Thanks for the quick work!
John
Information forwarded
to guix-patches@gnu.org: bug#70113; Package guix-patches.
(Tue, 02 Apr 2024 13:25:02 GMT) (full text, mbox, link).
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 <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
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
Reply sent
to Leo Famulari <leo@famulari.name>:
You have taken responsibility.
(Wed, 03 Apr 2024 22:09:05 GMT) (full text, mbox, link).
Notification sent
to Leo Famulari <leo@famulari.name>:
bug acknowledged by developer.
(Wed, 03 Apr 2024 22:09:05 GMT) (full text, mbox, link).
On Tue, Apr 02, 2024 at 03:23:44AM +0000, John Kehayias wrote:
> Overall changes look good, but I have not had a chance to try it locally
> (building or dependents).
I successfully tested with the file-roller package, which depends
directly on libarchive and no other related packages. I think it's a
reasonable basic test case.
I agree it's a good idea to look into a more comprehensive update to
libarchive, but I just wanted to get this patch in ASAP.
Pushed as 629614c7a3f9283306939402f1ff46914f327c21
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
Added tag(s) security.
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Sun, 07 Apr 2024 20:42:02 GMT) (full text, mbox, link).
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Mon, 06 May 2024 11:24:06 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.