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

[Leo Famulari]

On Sun, Feb 11, 2018 at 02:27:44AM +0100, Marius Bakke wrote:
> I was digging through the GitHub mirror, but haven't been able to find the 
> commit(s) in question:

I haven't found them either.


signature.asc
Description: PGP signature

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

[Marius Bakke]

On February 10, 2018 10:49:52 PM GMT+01:00, Leo Famulari  
wrote:
>I'm trying to update LibreOffice to 5.4.5.1.
>
>This version of LibreOffice requires cppunit to be updated to 1.14.0.
>
>However, this new version of cppunit requires C++11.
>
>This is not the default C++ standard in GCC 5, so this update requires
>sprinkling "CXXFLAGS=-std=c++11" across several packages, AFAICT.

Could we package the newer version separately and override CXXFLAGS for 
libreoffice only?


>I'd rather try cherry-picking a patch from LibreOffice upstream but
>their Git repo is several gigabytes and it will take hours for me to
>download it.

I was digging through the GitHub mirror, but haven't been able to find the 
commit(s) in question:

https://github.com/LibreOffice/core

Thanks for working on it!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Leo Famulari]

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?

It's too late in this cycle. Upgrading glibc would require a full
rebuild and would introduce new failures.


signature.asc
Description: PGP signature

bug#23364: python-statsmodels build failures

[Leo Famulari]

On Sat, Feb 10, 2018 at 05:07:03PM -0500, Mark H Weaver wrote:
> reopen 23364
> thanks
> 
> Andreas Enge  writes:
> 
> > This has probably been fixed in the following commit:
> >
> > commit 25b2c47d753efd0761a4e16519dce38d828789f5
> > Author: Hartmut Goebel 
> > Date:   Sun Oct 16 18:40:58 2016 +0200
> >
> > gnu: python-statsmodels: Fix build
> >
> > * gnu/packages/statistics.scm (python-statsmodels): [check] set
> >   PYTHONPATH prior to running tests.
> >
> > In any case the package did compile in 2017, and was updated later to 0.8.0.
> 
> No, there have been over 200 nondeterministic build failures of
> python-statsmodels since that commit, including over 140 failures of
> 0.8.0.  I usually have to ask Hydra to attempt to rebuild it several
> times before it finally succeeds.

I wonder if the test suite is really worth running in this case? Maybe
we should just report the failures upstream and skip the tests.


signature.asc
Description: PGP signature

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

[Chris Marusich]

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?

-- 
Chris


signature.asc
Description: PGP signature

bug#23364: python-statsmodels build failures

[Mark H Weaver]

reopen 23364
thanks

Andreas Enge  writes:

> This has probably been fixed in the following commit:
>
> commit 25b2c47d753efd0761a4e16519dce38d828789f5
> Author: Hartmut Goebel 
> Date:   Sun Oct 16 18:40:58 2016 +0200
>
> gnu: python-statsmodels: Fix build
>
> * gnu/packages/statistics.scm (python-statsmodels): [check] set
>   PYTHONPATH prior to running tests.
>
> In any case the package did compile in 2017, and was updated later to 0.8.0.

No, there have been over 200 nondeterministic build failures of
python-statsmodels since that commit, including over 140 failures of
0.8.0.  I usually have to ask Hydra to attempt to rebuild it several
times before it finally succeeds.

   Mark

--8<---cut here---start->8---
hydra=> select build, stepnr as step, case when busy=1 then 'busy' when 
status=0 then NULL when status=1 then 'fail' when status=4 then 'abort' when 
status=7 then 'timeout' when status=8 then 'cfail' else '?' end as stat, 
machine, drvpath, system, to_timestamp(stoptime) as finished from buildsteps 
where drvpath~'-statsmodels-' and status<>0 order by stoptime desc limit 200;
  build  | step | stat  | machine | 
 drvpath  |system|finished  
  
-+--+---+-+---+--+
 2489145 |1 | fail  | hydra.gnunet.org| 
/gnu/store/r25anrxjhjzf4j5qszifs5gn58in9sb1-python-statsmodels-0.8.0.drv  | 
x86_64-linux | 2018-02-10 16:11:56+00
 2360745 |1 | fail  | hydra.gnunet.org| 
/gnu/store/gxr86fpw2d0h71h6i44nvqz91nnspyns-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-26 12:06:28+00
 2359647 |1 | fail  | hydra.gnunet.org| 
/gnu/store/f7md20hsag665xc24b35cjb43nym8qif-python2-statsmodels-0.8.0.drv | 
i686-linux   | 2017-11-23 12:11:37+00
 2359361 |1 | fail  | | 
/gnu/store/f7md20hsag665xc24b35cjb43nym8qif-python2-statsmodels-0.8.0.drv | 
 | 2017-11-23 12:11:37+00
 2359316 |1 | fail  | hydra.gnunet.org| 
/gnu/store/kwa6jc47iqxxqzalhp1nxmbdrf4d8n54-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-23 12:00:02+00
 2352814 |2 | fail  | hydra.gnunet.org| 
/gnu/store/z7xhrqrqxdw2ilv0vi8c5v4i0f6w1rl8-python2-statsmodels-0.8.0.drv | 
i686-linux   | 2017-11-17 01:13:41+00
 2353500 |2 | fail  | | 
/gnu/store/z7xhrqrqxdw2ilv0vi8c5v4i0f6w1rl8-python2-statsmodels-0.8.0.drv | 
 | 2017-11-17 01:13:41+00
 2353640 |1 | fail  | hydra.gnunet.org| 
/gnu/store/dmi91sribad72dcix730mdsyjz7kq0q1-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-14 23:17:39+00
 2353500 |1 | fail  | | 
/gnu/store/z7xhrqrqxdw2ilv0vi8c5v4i0f6w1rl8-python2-statsmodels-0.8.0.drv | 
 | 2017-11-14 11:46:48+00
 2352814 |1 | fail  | hydra.gnunet.org| 
/gnu/store/z7xhrqrqxdw2ilv0vi8c5v4i0f6w1rl8-python2-statsmodels-0.8.0.drv | 
i686-linux   | 2017-11-14 11:46:45+00
 2350115 |1 | fail  | hydra.gnunet.org| 
/gnu/store/h2k7ik492kxhrb9lmma65mskjapqn8yi-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-10 22:26:19+00
 2346540 |1 | fail  | hydra.gnunet.org| 
/gnu/store/xrkag19iwfjkzw6zrs6axgrj48qgb6mx-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-08 06:23:15+00
 2343300 |2 | fail  | hydra.gnunet.org| 
/gnu/store/z34z59ix860f6l6b41r285fhvdzgipsy-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-02 20:41:31+00
 2343300 |1 | fail  | hydra.gnunet.org| 
/gnu/store/z34z59ix860f6l6b41r285fhvdzgipsy-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-11-02 17:10:50+00
 2337232 |2 | fail  | hydra.gnunet.org| 
/gnu/store/m0m01x5qhw7jcqhx7n76di4cxr3qj4z3-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-10-31 00:58:36+00
 2336654 |2 | fail  | | 
/gnu/store/yhv06b8948i9hl53c32pvyg5jybq14qm-python2-statsmodels-0.8.0.drv | 
 | 2017-10-31 00:02:32+00
 2336469 |2 | fail  | hydra.gnunet.org| 
/gnu/store/yhv06b8948i9hl53c32pvyg5jybq14qm-python2-statsmodels-0.8.0.drv | 
i686-linux   | 2017-10-31 00:02:32+00
 2329493 |1 | fail  | hydra.gnunet.org| 
/gnu/store/d6rcas920ag6a8yhzdvp1vjzd59g2ay2-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-10-23 00:59:42+00
 2331510 |1 | fail  | hydra.gnunet.org| 
/gnu/store/0vbrycraw0md7b2gsdz99qx0rk8sk74m-python-statsmodels-0.8.0.drv  | 
i686-linux   | 2017-10-21 12:06:46+00
 2324420 |1 | abort | hydra.gnunet.org| 
/gnu/store/3nyj73qglz0xnw0pb58sfc2x03zjh00d-python-statsmodels-0.8.0.drv  | 
x86_64-linux | 2017-10-18 10:05:58+00
 2320900 |1 | fail  | hydra.gnunet.org| 
/gnu/store/gmmc15crn9dc550ki12ri6dqny8n30ah-python-statsmodels-0.8.0.drv  | 
i686-linux   | 20

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

[Leo Famulari]

I'm trying to update LibreOffice to 5.4.5.1.

This version of LibreOffice requires cppunit to be updated to 1.14.0.

However, this new version of cppunit requires C++11.

This is not the default C++ standard in GCC 5, so this update requires
sprinkling "CXXFLAGS=-std=c++11" across several packages, AFAICT.

I'd rather try cherry-picking a patch from LibreOffice upstream but
their Git repo is several gigabytes and it will take hours for me to
download it.


signature.asc
Description: PGP signature

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

[Leo Famulari]

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


signature.asc
Description: PGP signature

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

[Leo Famulari]

We need to fix CVE-2018-6871 in our LibreOffice package. This bug allows
remote attackers to read any file accessible from LibreOffice by
supplying a crafted file to open in LibreOffice.

Apparently the bug is fixed in LibreOffice 5.4.5 or 6.0.1.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6871
https://github.com/jollheef/libreoffice-remote-arbitrary-file-disclosure


signature.asc
Description: PGP signature

bug#30413: file exists and is +x but cannot be executed

[Marco van Hulten]

Hello—

I had cups installed as root and another user.  I could use lpr.
Now I tried to install it under user2 (to have the lpr binary
available, among other things), but I cannot execute `lpr`:


user2@graviton ~$ guix package -i cups
The following package will be upgraded:
   cups 2.2.4 → 2.2.4   /gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4

nothing to be done
user2@graviton ~$ lpr
lpr: No such file or directory
user2@graviton ~$ which lpr
/home/user2/.guix-profile/bin/lpr
user2@graviton ~$ ls -l /home/user2/.guix-profile/bin/lpr
lrwxrwxrwx 11 root root 62 Jan  1 1970 /home/user2/.guix-profile/bin/lpr
-> /gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr
user2@graviton ~$ ls -l
/gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr
-r-xr-xr-x 2 root root 14624 Jan  1 1970 
/gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr
user2@graviton ~$ /gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr
/gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr: No such file or 
directory
user2@graviton ~$ file 
/gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr
/gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr: ELF 64-bit LSB 
shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/ld-linux-x86-64.so.2,
 or GNU/Linux 2.6.32, stripped, with debug_info


But it looks as if it is there.  Also, the executable bit is set for
world.


user2@graviton ~$ less 
/gnu/store/x5d85f1n0qalqlrr7rfwrj135m80snlb-cups-2.2.4/bin/lpr


showed the name of a file, so I checked its existence as well:


user2@graviton ~$ file 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/ld-linux-x86-64.so.2 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/ld-linux-x86-64.so.2:
 symbolic link to ld-2.25.so
user2@graviton ~$ cd /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/
user2@graviton /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib$
file ld-2.25.so ld-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, not stripped, with debug_info


I am using GNU Guix of a week old or so.

—Marco

bug#30396: nscd segfaults on attempt to ssh to .local host

[myglc2]

On 02/09/2018 at 22:56 Ludovic Courtès writes:

> George myglc2 Clemmer  skribis:
>
>> On 02/09/2018 at 14:18 Ludovic Courtès writes:
>>
>>> For now I’ve pushed a workaround in
>>> a68fdfea96370c8a4b95af1fcd6e2fd7eb72da29, which basically downgrades to
>>> 0.10 until upstream comes up with a fix.
>>
>> FWIW, nss-mdns-0.10 segfaults also ...

ARGH!... my mistake, I was looking at ...

g1@g1 ~$   guix gc -R $(readlink -f /run/current-system) | grep nss-mdns
/gnu/store/mvjz94idlcralc0bmqvrbrxx89w0narf-nss-mdns-0.10

... bug I had not rebooted/restarted herd.  Many thanks - George

bug#30365: Offloading sometimes hangs

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

>> 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!

Well it did show up again during the night.  :-/  So the problem appears
less frequently it seems, but it still appears.

A related issue is that ‘guix offload’ doesn’t time out in this case
but it probably should.

Ludo’.