bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)

[Bengt Richter]

Hi Ludo,

On +2019-10-18 16:36:30 +0200, Ludovic Courtès wrote:
> Bengt Richter  skribis:
> 
> > On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:
> 
> [...]
> 
> >> > Imperialist nitpick: why list the foreigners first?  :-)
> >> >
> >> > Anti-imperialist nitpick: reversing the two allows using ‘other
> >> > distributions’ instead of ‘foreign’ which always sounds a bit
> >> > dismissive to my ears.
> >> >
> >> > End nitpick.
> >> 
> >> That makes sense to me; I’m not satisfied with “foreign” either (I think
> >> the inspiration came from FFIs, but still).  Maybe “fellow distros”?
> >> :-)
> >
> > Is not the important distinction whether the "foreign distro" can be 
> > generated
> > with pure guix libre components using a pure guix tool chain vs not?
> 
> “Foreign distro” designates any distro other than Guix System.  From a
> technical viewpoint, it’s sometimes useful to be able to make that
> distinction.
> 
> HTH,
> Ludo’.

I was trying to get to a more exact definition of "that distinction" :)

I have read the page at "info guix installation", where "foreign" is explained:
---
 Note: We recommend the use of this shell installer script
 (https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh)
 to install Guix on top of a running GNU/Linux system, thereafter
 called a “foreign distro”.(1)  The script automates the download,
 installation, and initial configuration of Guix.  It should be run
 as the root user.

   When installed on a foreign distro, GNU Guix complements the
available tools without interference.  Its data lives exclusively in two
directories, usually ‘/gnu/store’ and ‘/var/guix’; other files on your
system, such as ‘/etc’, are left untouched.
[...]

(1) This section is concerned with the installation of the package
manager, which can be done on top of a running GNU/Linux system.  If,
instead, you want to install the complete GNU operating system, *note
System Installation::.
---

I have also read from "info guix introduction":
-
   (2) We used to refer to Guix System as “Guix System Distribution” or
“GuixSD”.  We now consider it makes more sense to group everything under
the “Guix” banner since, after all, Guix System is readily available
through the ‘guix system’ command, even if you’re using a different
distro underneath!


further along it says:
---
   With Guix System, you _declare_ all aspects of the operating system
configuration and Guix takes care of instantiating the configuration in
a transactional, reproducible, and stateless fashion (*note System
Configuration::).  Guix System uses the Linux-libre kernel, the Shepherd
initialization system (*note (shepherd)Introduction::), the well-known
GNU utilities and tool chain, as well as the graphical environment or
system services of your choice.
---

That sounds more restricted than "... even if you’re using a different
distro underneath!" 

When you say "Guix System," do/should you really mean _only_ a system 
specifically
running a linux-libre kernel, built with no dependencies outside of GuixSD
official sources, and using Shepherd initialization??

E.g., the purism OS has (UIAM) been recognized as free as in RMS's "ryf" but is 
it
compiled entirely using only tools in /gnu/store/... ?

Ask them, right? ;-)
(BTW, does anyone in the guix community have contact with them?
I think they are trying to contribute upstream and do "The Right Thing"(TM))

My point is, if e.g. a bug is caused by something that is different in their 
kernel image
from the one you generate from linux-libre and GuixSD sources, then we will be 
chasing a bug
in their build process, not ours.

Sometimes it might be "useful to be able to make that distinction" no? :)

(kernel image is just an example, likewise for initrd's or anything that runs 
that was not derived
from official guix/GuixSD sources).

BTW, Is it safe to do "guix system reconfigure" naively, "... even if you’re 
using a different
distro underneath!" ?? I am afraid to try it :)

--
Regards,
Bengt Richter

PS. I think it would be useful if there were a 
LD_IMPURE_REFERENCE_LOG="path/to/logfile.txt"
in an easy-to-edit place that, if present, would cause the ld wrapper to append 
to log what
it finds (even if otherwise ignoring impure refs)
WDYT?

bug#37810: Rust 1.27 and later depends on GDB 8.2

[Marius Bakke]

Hello,

After updating to GDB 8.3, the Rust 1.27 test suite started failing:

https://ci.guix.gnu.org/build/1840276/details

Here are the relevant lines from the log file:

--8<---cut here---start->8---
failures:

 [debuginfo-gdb] debuginfo/pretty-uninitialized-vec.rs stdout 


NOTE: compiletest thinks it is using GDB with native rust support
executing 
"/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc"
 
"/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/src/test/debuginfo/pretty-uninitialized-vec.rs"
 "-L" 
"/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/test/debuginfo"
 "--target=x86_64-unknown-linux-gnu" "-C" "prefer-dynamic" "-o" 
"/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec.stage2-x86_64-unknown-linux-gnu"
 "-Crpath" "-Zunstable-options" 
"-Lnative=/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "-g" "-L" 
"/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec.stage2-x86_64-unknown-linux-gnu.gdb.aux"
--stdout--

--stderr--
warning: value assigned to `vec` is never read
  --> 
/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/src/test/debuginfo/pretty-uninitialized-vec.rs:32:5
   |
32 | vec = vec![0];
   | ^^^
   |
   = note: #[warn(unused_assignments)] on by default


--
NOTE: compiletest thinks it is using GDB version 8003001
executing "/gnu/store/5zmxrq9fyap51n98dxq1frgbzv9iqdg0-gdb-8.3.1/bin/gdb" 
"-quiet" "-batch" "-nx" 
"-command=/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec.debugger.script"
--stdout--
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x1710: file 
/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/src/test/debuginfo/pretty-uninitialized-vec.rs,
 line 31.
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/libthread_db.so.1".

Breakpoint 1, pretty_uninitialized_vec::main () at 
/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/src/test/debuginfo/pretty-uninitialized-vec.rs:31
31  zzz(); // #break
$1 = Vec(len: 140737488339712, cap: 140737345884160) = {
--stderr--
/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec.debugger.script:10:
 Error in sourced command file:
Cannot access memory at address 0x2

--

error: gdb failed to execute
status: exit code: 1
command: "/gnu/store/5zmxrq9fyap51n98dxq1frgbzv9iqdg0-gdb-8.3.1/bin/gdb" 
"-quiet" "-batch" "-nx" 
"-command=/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/build/x86_64-unknown-linux-gnu/test/debuginfo/pretty-uninitialized-vec.debugger.script"
stdout:
--
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x1710: file 
/tmp/guix-build-rust-1.27.2.drv-0/rustc-1.27.2-src/src/test/debuginfo/pretty-uninitialized-vec.rs,
 line 31.
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/libthread_db.so.1".

Breakpoint 1, pretty_uninitialized_vec::main () at 
/tmp/guix-build-rust

bug#37789: guix pull: error: You found a bug: the program

[George Clemmer]

Ludovic Courtès  writes:

> This is not the key of ci.guix.gnu.org.

Thanks for getting back to me. It turns out I mistakenly gave you this
server's public key. SORRY. Also I forgot the system is configured not
to use substitutes ...

   (guix-service-type
config =>
(guix-configuration
 (inherit config)
 (use-substitutes? #f)
 (substitute-urls (list "https://mirror.hydra.gnu.org";
"https://hydra.gnu.org";
"https://berlin.guixsd.org";))
 (extra-options '("--gc-keep-derivations=yes"
  "--gc-keep-outputs=yes"
  "--cores=0" "--max-jobs=10"))
 

... because it primarily builds Guix from Git. I only use 'guix pull' as
a kind of "rescue move" when the souce build fails, as it is now doing

configure: error: Guile-JSON is missing; please install it.

The last time I used 'guix pull' it worked fine ...

  /home/glc/.config/guix:
  lrwxrwxrwx 1 glc users   44 Dec 14  2018 current ->
  /var/guix/profiles/per-user/glc/current-guix

The guix-configuration is unchanged since then. Shouldn't 'guix pull'
still work?

SORRY for the run-around on keys and substitutes.

TIA, George

bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)

[Ludovic Courtès]

Bengt Richter  skribis:

> On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:

[...]

>> > Imperialist nitpick: why list the foreigners first?  :-)
>> >
>> > Anti-imperialist nitpick: reversing the two allows using ‘other
>> > distributions’ instead of ‘foreign’ which always sounds a bit
>> > dismissive to my ears.
>> >
>> > End nitpick.
>> 
>> That makes sense to me; I’m not satisfied with “foreign” either (I think
>> the inspiration came from FFIs, but still).  Maybe “fellow distros”?
>> :-)
>
> Is not the important distinction whether the "foreign distro" can be generated
> with pure guix libre components using a pure guix tool chain vs not?

“Foreign distro” designates any distro other than Guix System.  From a
technical viewpoint, it’s sometimes useful to be able to make that
distinction.

HTH,
Ludo’.

bug#37801: Possible insight into issue #30756 #include_next bug

[Carl Dong]

Hi Danny,

Thank you so much for the links and quotes, I'm definitely going to refer back
to them in the future and you probably saved me dozens of hours :-)

> I think so. I can't figure out why Guix is not just setting up CROSS_CPATH
> on its own in the first place.
> gnu/packages/cross-base.scm DOES have a search-path specification for
> CROSS_CPATH.

Perhaps Ludovic can confirm this, but I believe the reason why Guix is not
setting up CROSS_CPATH is because it doesn't _know_ it's cross-compiling. Guix
only sets up CROSS_CPATH when we invoke on the command line with
--target=x86_64-w64-mingw32 or something like that. I'm not exactly sure what a
clean solution to this is, but I'd hope we can find one in the future.

I'm thinking that the reason why my final solution involved explicitly setting
the exact ordering in my CROSS_CPLUS_INCLUDE_PATH was because mingw-w64 is
considered to be libc and that makes it special somehow. Not 100% sure though.

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"

bug#37779: encfs build fails: stdlib.h: No such file or directory

[Marius Bakke]

Pierre Neidhardt  writes:

> Since the move to gcc 7, encfs cannot be built:
>
> --8<---cut here---start->8---
> In file included from 
> /tmp/guix-build-encfs-1.9.5.drv-0/encfs-1.9.5/vendor/github.com/muflihun/easyloggingpp/src/easylogging++.h:340:0,
>from 
> /tmp/guix-build-encfs-1.9.5.drv-0/encfs-1.9.5/vendor/github.com/muflihun/easyloggingpp/src/easylogging++.cc:17:
> /gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++/cstdlib:75:15:
>  fatal error: stdlib.h: No such file or directory
>  #include_next 
>^~
> compilation terminated.
> --8<---cut here---end--->8---

Fixed in 1df9245586939e5a359f8c486662642d9d5998b5, thanks!


signature.asc
Description: PGP signature

bug#37778: ucl build fails: ACC conformance test failed.

[Marius Bakke]

Pierre Neidhardt  writes:

> ucl fails to build since the core-updates merge:
>
> --8<---cut here---start->8---
> ...
> checking whether your compiler passes the ACC conformance test... FAILED
> configure: 
> configure: Your compiler failed the ACC conformance test - for details see 
> configure: `config.log'. Please check that log file and consider sending
> configure: a patch or bug-report to .
> configure: Thanks for your support.
> configure: 
> configure: error: ACC conformance test failed. Stop.
> command 
> "/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" 
> "./configure" 
> "CONFIG_SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash"
>  
> "SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash"
>  "--prefix=/gnu/store/qgykbkkqm8s9xbplfjkf0852yswa0bah-ucl-1.03" 
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with status 
> 1
> --8<---cut here---end--->8---

Fixed in 7349f926c70d92b4ade0da2201d0df797e73fe07, thanks!


signature.asc
Description: PGP signature

bug#37533: waybar fails to build

[Efraim Flashner]

Closing this bug for now. We can reopen it if it becomes a problem
again.


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


signature.asc
Description: PGP signature

bug#37803: [BUG] installer does seem to know about pep8 patch

[P via Bug reports for GNU Guix]

‐‐‐ Original Message ‐‐‐
On Friday, October 18, 2019 2:48 AM, Kyle Andrews  
wrote:

> I just tried to install guix on desktop system by piggy-backing from a
> disk-image created on a laptop.
>
> I chose "Guided - using the entire disk with encryption" option.
>
> I then selected GNOME, openbox, and ratpoison to be installed as desktop
> environments. I'm not sure if that's relevant, but wanted to be thorough
> in case this may be limited to a GNOME issue.
>
> The installation errored out with the following message:
>
> > guix system: error: python-pep8-stdlib-tokenize-compat.patch: patch not 
> > found
>
> Thus the guix on the disk image seems to be missing the patch mentioned
> in the issue below (corresponding to the python-pep8 package):
>
> https://issues.guix.gnu.org/issue/36643

The patch seems to be present in the latest master. I don't have space to test 
out the installer.

bug#37804: getmail service documentation error?

[pelzflorian (Florian Pelz)]

On Fri, Oct 18, 2019 at 10:02:31AM +0200, pelzflorian (Florian Pelz) wrote:
> On Fri, Oct 18, 2019 at 08:47:11AM +0100, Christopher Baines wrote:
> > The change and patch looks reasonable to me.
> 
> 
> Pushed.  Thank you!
> 
> 
> 

I forgot prefixing the commit with doc.  Too late now.  Sorry.

bug#37804: getmail service documentation error?

[pelzflorian (Florian Pelz)]

On Fri, Oct 18, 2019 at 08:47:11AM +0100, Christopher Baines wrote:
> The change and patch looks reasonable to me.


Pushed.  Thank you!

bug#37804: getmail service documentation error?

[Christopher Baines]

pelzflorian (Florian Pelz)  writes:

> The documentation of the getmail service’s delete_after setting is
> confusing and appears to contradict upstream documentation at
> .
>
> I am not sure, but the code in the getmail file in the getmail source
> code also appears to call destination.deliver_message before deleting,
> in agreement with upstream.
>
> Can someone with knowledge check?  Shall I push the attached patch?

The change and patch looks reasonable to me.


signature.asc
Description: PGP signature

bug#37804: getmail service documentation error?

[pelzflorian (Florian Pelz)]

The documentation of the getmail service’s delete_after setting is
confusing and appears to contradict upstream documentation at
.

I am not sure, but the code in the getmail file in the getmail source
code also appears to call destination.deliver_message before deleting,
in agreement with upstream.

Can someone with knowledge check?  Shall I push the attached patch?

Regards,
Florian
>From 971fee0af8908acdc73498917a8a55811122ac8e Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Fri, 18 Oct 2019 08:52:12 +0200
Subject: [PATCH] Fix documentation of delete_after in the getmail service.

* doc/guix.texi (Getmail service): Remove the word `not'.
* gnu/services/getmail.scm (getmail-options-configuration): Ditto.
---
 doc/guix.texi| 2 +-
 gnu/services/getmail.scm | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index a38eb2aa7c..32d2ffe044 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -17435,7 +17435,7 @@ Defaults to @samp{#f}.
 
 @deftypevr {@code{getmail-options-configuration} parameter} 
non-negative-integer delete-after
 Getmail will delete messages this number of days after seeing them, if
-they have not been delivered.  This means messages will be left on the
+they have been delivered.  This means messages will be left on the
 server this number of days after delivering them.  A value of @samp{0}
 disabled this feature.
 
diff --git a/gnu/services/getmail.scm b/gnu/services/getmail.scm
index b807bb3a5d..b3d86cb65c 100644
--- a/gnu/services/getmail.scm
+++ b/gnu/services/getmail.scm
@@ -176,8 +176,8 @@ server.")
   (delete-after
(non-negative-integer 0)
"Getmail will delete messages this number of days after seeing them, if
-they have not been delivered.  This means messages will be left on the server
-this number of days after delivering them.  A value of @samp{0} disabled this
+they have been delivered.  This means messages will be left on the server this
+number of days after delivering them.  A value of @samp{0} disabled this
 feature.")
   (delete-bigger-than
(non-negative-integer 0)
-- 
2.23.0