bug#30414: Libreoffice CVE-2018-6871 [remote read of any local files]

[Leo Famulari]

On Sun, Feb 11, 2018 at 02:29:02PM +, Marius Bakke wrote:
> I gave this a go, and there were (of course) a lot more changes
> necessary to make this newer libreoffice build.  In particular, it now
> works with an external xmlsec (albeit NSS only), and it wants to build
> PDFium(!) in the same fashion as xmlsec was previously.
> 
> However PDFium fails to build due to requiring newer C++ features, and
> my attempts at patching "external/pdfium/Library_pdfium.mk" to add
> CXXFLAGS were unsuccessful.  So in the end I disabled PDFium support.
> 
> It also required libjpeg-turbo instead of libjpeg, although this is
> supposedly fixed in 6.0.1:
> .
>
> Then there were some other problems related to not finding GPGME
> headers, as well as an upstream regression when GTK2 support is
> disabled.
> 
> Without further ado, here is the patch.  I'm still building it, but plan
> to push shortly if there are no further issues. 

Wow, thank you!

> From a28e82e1e3d480d5edf374cea062536d4c8d6d82 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Sun, 11 Feb 2018 11:46:27 +0100
> Subject: [PATCH] gnu: libreoffice: Update to 5.4.5.1 [CVE-2018-6871].
> 
> * gnu/packages/check.scm (cppunit-1.14): New public variable.
> * gnu/packages/libreoffice.scm (xmlsec-src-libreoffice): Remove variable.
> (libreoffice): Update to 5.4.5.1.
> [native-inputs]: Change CPPUNIT to CPPUNIT-1.14.
> [inputs]: Add GPGME and XMLSEC-NSS.  Remove XMLSEC-SRC-LIBREOFFICE.  Replace
> LIBJPEG with LIBJPEG-TURBO.
> [arguments]: Remove xmlsec code from PREPARE-SRC-PHASE.  Make sure GPGME++
> headers are found.  Add workaround for .  Add
> "--disable-pdfium" to #:configure-flags.
> * gnu/packages/xml.scm (xmlsec-nss): New public variable.

The only change I suggest is to remove the obsolete comment at the
beginning of libreoffice's native-inputs about the xmlsec tarball.


signature.asc
Description: PGP signature

bug#30414: Libreoffice CVE-2018-6871 [remote read of any local files]

[Marius Bakke]

Leo Famulari  writes:

>> From a28e82e1e3d480d5edf374cea062536d4c8d6d82 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> Date: Sun, 11 Feb 2018 11:46:27 +0100
>> Subject: [PATCH] gnu: libreoffice: Update to 5.4.5.1 [CVE-2018-6871].
>> 
>> * gnu/packages/check.scm (cppunit-1.14): New public variable.
>> * gnu/packages/libreoffice.scm (xmlsec-src-libreoffice): Remove variable.
>> (libreoffice): Update to 5.4.5.1.
>> [native-inputs]: Change CPPUNIT to CPPUNIT-1.14.
>> [inputs]: Add GPGME and XMLSEC-NSS.  Remove XMLSEC-SRC-LIBREOFFICE.  Replace
>> LIBJPEG with LIBJPEG-TURBO.
>> [arguments]: Remove xmlsec code from PREPARE-SRC-PHASE.  Make sure GPGME++
>> headers are found.  Add workaround for .  Add
>> "--disable-pdfium" to #:configure-flags.
>> * gnu/packages/xml.scm (xmlsec-nss): New public variable.
>
> The only change I suggest is to remove the obsolete comment at the
> beginning of libreoffice's native-inputs about the xmlsec tarball.

Good catch.  It seems the autoconf and automake inputs are no longer
required.  But I unfortunately spoke too soon earlier, it failed very
late in the build:

[build CMP] filter/source/xsltdialog/xsltdlg
ld: cannot find -lltdl
collect2: error: ld returned 1 exit status
make[1]: *** 
[/tmp/guix-build-libreoffice-5.4.5.1.drv-0/libreoffice-5.4.5.1/xmlsecurity/Library_xsec_xmlsec.mk:10:
 
/tmp/guix-build-libreoffice-5.4.5.1.drv-0/libreoffice-5.4.5.1/instdir/program/libxsec_xmlsec.so]
 Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:269: build] Error 2
phase `build' failed after 2114.1 seconds

I've attached a revised patch that adds libltdl, and removes the
automake inputs.  However, I have to leave now, so could you please
verify that it works and push?  I can provide moral support on #guix if
nothing else :-)

TIA!
From 78a216026cc5d4be4e1623fbe8b3632f47b99ef8 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 11 Feb 2018 11:46:27 +0100
Subject: [PATCH] gnu: libreoffice: Update to 5.4.5.1 [CVE-2018-6871].

* gnu/packages/check.scm (cppunit-1.14): New public variable.
* gnu/packages/libreoffice.scm (xmlsec-src-libreoffice): Remove variable.
(libreoffice): Update to 5.4.5.1.
[native-inputs]: Change CPPUNIT to CPPUNIT-1.14.  Remove AUTOCONF and AUTOMAKE.
[inputs]: Add GPGME, XMLSEC-NSS and LIBLTDL.  Remove XMLSEC-SRC-LIBREOFFICE.
Replace LIBJPEG with LIBJPEG-TURBO.
[arguments]: Remove xmlsec code from PREPARE-SRC-PHASE.  Make sure GPGME++
headers are found.  Add workaround for .  Add
"--disable-pdfium" to #:configure-flags.
* gnu/packages/xml.scm (xmlsec-nss): New public variable.
---
 gnu/packages/check.scm   | 17 +++
 gnu/packages/libreoffice.scm | 70 
 gnu/packages/xml.scm | 12 +++-
 3 files changed, 59 insertions(+), 40 deletions(-)

diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
index 1276c0fda..92f493592 100644
--- a/gnu/packages/check.scm
+++ b/gnu/packages/check.scm
@@ -157,6 +157,23 @@ unit testing.  Test output is in XML for automatic testing and GUI based for
 supervised tests.")
 (license license:lgpl2.1))) ; no copyright notices. LGPL2.1 is in the tarball
 
+;; Some packages require this newer version of cppunit.  However, it needs
+;; C++11 support, which is not enabled by default in our current GCC, and
+;; updating in-place would require adding CXXFLAGS to many dependent packages.
+;; Thus, keep as a separate variable for now.
+;; TODO: Remove this when our default GCC is updated to 6 or higher.
+(define-public cppunit-1.14
+  (package
+(inherit cppunit)
+(version "1.14.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://dev-www.libreoffice.org/src/;
+  "cppunit-" version ".tar.gz"))
+  (sha256
+   (base32
+"1027cyfx5gsjkdkaf6c2wnjh68882grw8n672018cj3vs9lrhmix"))
+
 (define-public catch-framework
   (package
 (name "catch")
diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm
index 799b06243..47dd21b3b 100644
--- a/gnu/packages/libreoffice.scm
+++ b/gnu/packages/libreoffice.scm
@@ -7,7 +7,7 @@
 ;;; Copyright © 2017 Tobias Geerinckx-Rice 
 ;;; Copyright © 2017 Andy Wingo 
 ;;; Copyright © 2017 Ludovic Courtès 
-;;; Copyright © 2017 Marius Bakke 
+;;; Copyright © 2017, 2018 Marius Bakke 
 ;;; Copyright © 2017 Rutger Helling 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -54,6 +54,7 @@
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gperf)
+  #:use-module (gnu packages gnupg)
   #:use-module (gnu packages gnuzilla)
   #:use-module (gnu packages gstreamer)
   #:use-module (gnu packages gtk)
@@ -839,22 

bug#30414: Libreoffice CVE-2018-6871 [remote read of any local files]

[Leo Famulari]

On Sun, Feb 11, 2018 at 03:08:59PM +, Marius Bakke wrote:
> I've attached a revised patch that adds libltdl, and removes the
> automake inputs.  However, I have to leave now, so could you please
> verify that it works and push?  I can provide moral support on #guix if
> nothing else :-)

Can somebody else do this? I'm actually riding a bus right now and won't
be able to run this build long enough for it to complete.


signature.asc
Description: PGP signature

bug#30415: Unzip CVE-2018-1000031 and others

[Leo Famulari]

On Sat, Feb 10, 2018 at 01:57:28PM -0500, Leo Famulari wrote:
> We need to fix CVE-2018-131, CVE-2018-132, CVE-2018-133,
> CVE-2018-134, CVE-2018-135 in UnZip:
> 
> http://seclists.org/oss-sec/2018/q1/134
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-131 and etc

Okay, the advisory says that only CVE-2018-135 affects our UnZip 6.0
package; the other bugs were apparently introduced after that.

And CVE-2018-135 may be mitigated by the compiler. I'll investigate
more.


signature.asc
Description: PGP signature

bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Pjotr Prins]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic  writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

I think we should not update packages deep in the tree unless there is
a security patch. What we have now is well tested.

Pj.


-- 

bug#30401: gitolite some important hooks not working

[Ricardo Wurmus]

n...@crash.cx writes:

> A paste that lost its formatting but speaks for itself:
>
> Counting objects: 4, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (4/4), 1.03 KiB | 1.03 MiB/s, done.
> Total 4 (delta 0), reused 0 (delta 0)
> remote: Can't locate Data/Dumper.pm in @INC (you may need to
> install the Data::Dumper module) (@INC contains:
> /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib
> /home/git/.guix-profile/lib/perl5/site_perl /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.24.1
> /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24
> /usr/share/perl/5.24 /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base .) at

Have you tried propagating the perl-data-dumper package?  Or did you try
wrapping the executable in the PERL5LIB environment variable after
adding the package?

> Installing the module + perl into the profile didn't help either.

The gitolite executables need to be made aware of the location of the
Perl modules, so it’s expected that this wouldn’t help.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#30401: gitolite some important hooks not working

[ng0]

On Sun, 11 Feb 2018, Ricardo Wurmus  wrote:
> n...@crash.cx writes:
>
>> A paste that lost its formatting but speaks for itself:
>>
>> Counting objects: 4, done.
>> Delta compression using up to 4 threads.
>> Compressing objects: 100% (3/3), done.
>> Writing objects: 100% (4/4), 1.03 KiB | 1.03 MiB/s, done.
>> Total 4 (delta 0), reused 0 (delta 0)
>> remote: Can't locate Data/Dumper.pm in @INC (you may need to
>> install the Data::Dumper module) (@INC contains:
>> /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib
>> /home/git/.guix-profile/lib/perl5/site_perl /etc/perl
>> /usr/local/lib/x86_64-linux-gnu/perl/5.24.1
>> /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24
>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24
>> /usr/share/perl/5.24 /usr/local/lib/site_perl
>> /usr/lib/x86_64-linux-gnu/perl-base .) at
>
> Have you tried propagating the perl-data-dumper package?  Or did you try
> wrapping the executable in the PERL5LIB environment variable after
> adding the package?
>
>> Installing the module + perl into the profile didn't help either.
>
> The gitolite executables need to be made aware of the location of the
> Perl modules, so it’s expected that this wouldn’t help.

I had no time to reply so far or to try and other solutions.
Turns out so far that it works when you make /usr/bin/perl as a
special file type link available on the system, as the problem is
some unchanged hook lines pointing to this instead of the store.

As repo hooks are not attached to the changes in the store I
think it's okay. Eventually we should come up with a solution for
those hooks.
-- 
ng0 :: https://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

bug#30428: guix git-fetch doesn't specify "--depth 1" - git clone clones a lot without any use

[Danny Milosavljevic]

git-fetch doesn't allow specifying "--depth 1".

That means the repo clones are needlessly large.

Since in packages we only need one specific commit anyhow why do we fetch
all the other commits?

bug#30365: Offloading sometimes hangs

[Ricardo Wurmus]

Hi Ludo,

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> So what we have here is that the Scheme procedure ‘select’ returned
>> stdin as “ready for reading”.  How did that happen?  I believe this is
>> due to : ‘scm_i_prepare_to_wait_on_fd’
>> returns 1, so ‘select’ returns EINTR but it does so without clearing the
>> FD sets.
>
> I’ve pushed a workaround here:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8446dc5a360e3a13fecea870f86efdbd893e3905
>
> and guix-0.14.0-8.bc880f9 includes that fix.
>
> It’s been running for several hours on berlin, building a bunch of
> things notably on aarch64, and it seems to work well!

Congratulations on figuring this out!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net