bug#33848: Store references in SBCL-compiled code are "invisible"

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> That the scanner fails to find all references is clearly an important
> problem that should be fixed ASAP, but as far as I can tell, improving
> the grafter would not make that problem any worse or create any new
> problems.
>
> Improving the grafter should have the following effects:
>
> (1) Reducing the number of cases where ungrafted code with security
> flaws is being used on our systems.
>
> (2) Fixing problems in our Fish, Nyxt, and Common Lisp packages.

These are cases where the scanner may get the references wrong in the
first place though.

OTOH, there are also cases where the scanner gets the references right.
For example, earlier Pierre mentioned that grafting breaks the reference
of nyxt to glib:

  https://issues.guix.gnu.org/33848#26

It turns out that the scanner does find a reference to glib “by chance”:

--8<---cut here---start->8---
$ guix gc --references $(guix build nyxt --no-grafts) | grep glib-2
/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6
$ grep -r 4vmhbc31cpbnlw3c96kcc094ihmaf7dv  $(guix build nyxt --no-grafts)
Duuma dosiero 
/gnu/store/5pgh0cn1kzyajaanj7f1iyp91hd917d6-nyxt-2-pre-release-6/bin/.nyxt-real 
kongruas
--8<---cut here---end--->8---

So in this case, the fixed grafter is a net win.

After applying the patch you sent, I confirm that Nyxt starts just fine
when running:

  ./pre-inst-env guix environment --ad-hoc nyxt -CN -E ^DISPLAY 
--share=/tmp/.X11-unix -- nyxt

… whereas on master it fails to start with:

--8<---cut here---start->8---
Unhandled SIMPLE-ERROR in thread #:
  Problem running initialization hook GLIB::RUN-INITIALIZERS:
  Unable to load any of the alternatives:
   
("/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6/lib/libglib-2.0.so.0"

"/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6/lib/libglib-2.0.so")
--8<---cut here---end--->8---

> Improving the scanner, or adding phases to selected packages or build
> systems to copy hidden references to an ASCII file, should have the
> following effects:
>
> (1) Reducing the number of cases where run-time dependencies are not
> known to Guix, which could lead to dependencies being prematurely
> GC'd or excluded from things like "guix pack".
>
> So, it seems to me that we should persue both of these improvements
> concurrently, and I see no practical advantage to postponing one for the
> sake of rolling them both out at the same time.  Of course, I welcome
> other opinions on this.

As always I worry about added complexity.  In this case, I think you’re
right: the UTF-{16,32}-capable grafter would most likely fix a number of
issues right away, including this Nyxt issue.

Thanks!

Ludo’.

bug#33848: Store references in SBCL-compiled code are "invisible"

[Pierre Neidhardt]

Hi Mark, hi Ludo,

> After applying the patch you sent, I confirm that Nyxt starts just fine
> when running:
>
>   ./pre-inst-env guix environment --ad-hoc nyxt -CN -E ^DISPLAY 
> --share=/tmp/.X11-unix -- nyxt
>
> … whereas on master it fails to start with:
>
> --8<---cut here---start->8---
> Unhandled SIMPLE-ERROR in thread # {10010D0103}>:
>   Problem running initialization hook GLIB::RUN-INITIALIZERS:
>   Unable to load any of the alternatives:
>
> ("/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6/lib/libglib-2.0.so.0"
> 
> "/gnu/store/4vmhbc31cpbnlw3c96kcc094ihmaf7dv-glib-2.62.6/lib/libglib-2.0.so")
> --8<---cut here---end--->8---

Fantastic, this looks like it's fixing this grafting issue indeed!

I also agree this looks like a net win even though the `guix gc` issue
is not fix.
The latter seems to be relatively easier to fix, doesn't it?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.

[Maxime Devos]

On Mon, 2021-04-05 at 21:54 +0200, Ludovic Courtès wrote:
> [...]
> 
> OK.  It does mean that the bug is hardly exploitable in practice: you
> have to be able to log in at all,
Yes.

>  and if you’re able to log in, you have
> to log in precisely within the 1s (or less) that follows account
> creation, which sounds challenging (TCP + SSH connection establishment
> is likely to take as much time or more,

Is logging in possible when the home directory doesn't exist?
It isn't possible from the console.  I guess it isn't possible from SSH
either.

If it is possible,
then the window would be somewhat larger I think.  Account creation is done
at activation time, while creating home directories is done as a shepherd
service (see account-service-type in gnu/system/shadow.scm).

>  likewise for typing in your password.)
An attacker could copy and paste, or have used a single-character password,
to save some time.

>   It’s also one-time chance.

Yes.

> Do I get it right?

I think so, except the window might be larger (but still a one-time chance).

> Does it warrant as strong messaging as for the recent daemon
> ‘--keep-failed’ vulnerability?

As it is a one-time chance, with a limited window, and only under specific
circumstances (creating a new user account), I don't think so.  But I would
still recommend to upgrade.  Does the blog post have ‘too strong messaging’? 

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

bug#46362: got unexpected path `Backtrace:' from substituter

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

>> chino@asus-laptop:~$ guix build opencv 
>> --substitute-urls="https://mirror.sjtu.edu.cn/guix 
>> https://mirror.guix.org.cn https://mirror.c1r3u.xyz https://ci.guix.gnu.org";
>> substitute: updating substitutes from 'https://mirror.sjtu.edu.cn/guix'... 
>> 100.0%
>> substitute: 
>> guix build: error: got unexpected path `Backtrace:' from substituter
>> ```
>
> Commit ee3226e9d54891c7e696912245e4904435be191c addresses the
> error-reporting issue: now the backtrace will be properly displayed (we
> still need to update the ‘guix’ package before you can deploy the fix.)

This commit did the job, but there would still be cases where error
messages would end up on file descriptor 2 (not surprisingly) and which
the daemon would wrongfully interpret as a status message from ‘guix
substitute’, leading to obscure crashes.  Sébastien gives an example
at :

  guix install: error: got unexpected path 
`/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)' from substituter

The attached patch swaps use of file descriptors 2 and 4 of ‘guix
substitute’: FD 2 is now used for regular error reporting, while FD 4 is
used to communicate responses to the daemon.  This is more natural and
avoids the kind of problem discussed above.

I’ll push this change if there are no objections.

Thanks,
Ludo’.

>From d85353dd4bfaa57a7d5803dade91d806a169295a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Tue, 6 Apr 2021 12:10:29 +0200
Subject: [PATCH] daemon: 'guix substitute' replies on FD 4.

This avoids the situation where error messages would unintentionally go
to stderr and be wrongfully interpreted as a reply by the daemon.

Fixes .
This is a followup to ee3226e9d54891c7e696912245e4904435be191c.

* guix/scripts/substitute.scm (display-narinfo-data): Add 'port'
parameter and honor it.
(process-query): Likewise.
(process-substitution): Likewise.
(%error-to-file-descriptor-4?, with-redirected-error-port): Remove.
(%reply-file-descriptor): New variable.
(guix-substitute): Remove use of 'with-redirected-error-port'.  Define
'reply-port' and pass it to 'process-query' and 'process-substitution'.
* nix/libstore/build.cc (SubstitutionGoal::handleChildOutput): Swap
'builderOut' and 'fromAgent'.
* nix/libstore/local-store.cc (LocalStore::getLineFromSubstituter):
Likewise.
* tests/substitute.scm : Set '%reply-file-descriptor'
rather than '%error-to-file-descriptor-4?'.
---
 guix/scripts/substitute.scm | 183 +---
 nix/libstore/build.cc   |   4 +-
 nix/libstore/local-store.cc |  12 +--
 tests/substitute.scm|   4 +-
 4 files changed, 95 insertions(+), 108 deletions(-)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index 79eaabd8fd..48309f9b3a 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -63,7 +63,7 @@
   #:use-module (web uri)
   #:use-module (guix http-client)
   #:export (%allow-unauthenticated-substitutes?
-%error-to-file-descriptor-4?
+%reply-file-descriptor
 
 substitute-urls
 guix-substitute))
@@ -279,29 +279,29 @@ Internal tool to substitute a pre-built binary to a local build.\n"))
   "Evaluate EXP...  Return its CPU usage as a fraction between 0 and 1."
   (call-with-cpu-usage-monitoring (lambda () exp ...)))
 
-(define (display-narinfo-data narinfo)
-  "Write to the current output port the contents of NARINFO in the format
-expected by the daemon."
-  (format #t "~a\n~a\n~a\n"
+(define (display-narinfo-data port narinfo)
+  "Write to PORT the contents of NARINFO in the format expected by the
+daemon."
+  (format port "~a\n~a\n~a\n"
   (narinfo-path narinfo)
   (or (and=> (narinfo-deriver narinfo)
  (cute string-append (%store-prefix) "/" <>))
   "")
   (length (narinfo-references narinfo)))
-  (for-each (cute format #t "~a/~a~%" (%store-prefix) <>)
+  (for-each (cute format port "~a/~a~%" (%store-prefix) <>)
 (narinfo-references narinfo))
 
   (let-values (((uri compression file-size)
 (narinfo-best-uri narinfo
   #:fast-decompression?
   %prefer-fast-decompression?)))
-(format #t "~a\n~a\n"
+(format port "~a\n~a\n"
 (or file-size 0)
 (or (narinfo-size narinfo) 0
 
-(define* (process-query command
+(define* (process-query port command
 #:key cache-urls acl)
-  "Reply to COMMAND, a query as written by the daemon to this process's
+  "Reply on PORT to COMMAND, a query as written by the daemon to this process's
 standard input.  Use ACL as the access-control list against which to check
 authorized substitutes."
   (define valid?
@@ -338,17 +338,17 @@ a

bug#47614: [security] Chunked store references in .zo files in Racket 8

[Mark H Weaver]

On my system, Racket 8.0 contains a *.zo file that contains a *chunked*
store reference.  As a result, it retains a reference to the ungrafted
Gtk+, and therefore to the ungrafted glib, cairo, and libx11.

The file is:

  
/gnu/store/…-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/compiled/gtk3_rkt.zo,

and here's the relevant excerpt:

--8<---cut here---start->8---
mhw@jojen ~$ hexdump -C 
/gnu/store/…-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/compiled/gtk3_rkt.zo
 | grep -B2 -A6 /gnu/
0cf0  c0 06 23 00 06 36 02 31  c7 c6 46 25 02 61 7f 0b  |..#..6.1..F%.a..|
0d00  48 c7 c5 06 a3 01 28 67  03 32 01 08 0c 00 f0 23  |H.(g.2.#|
0d10  05 00 58 11 1e 26 48 2f  67 6e 75 2f 73 74 6f 72  |..X..&H/gnu/stor|
0d20  65 2f 6e 32 63 6e 70 32  66 69 76 78 71 31 30 6b  |e/n2cnp2fivxq10k|
0d30  78 71 61 6c 63 76 32 71  34 31 77 7a 73 79 6a 39  |xqalcv2q41wzsyj9|
0d40  79 64 62 01 d0 2b 2d 33  2e 32 34 2e 32 34 2f 6c  |ydb..+-3.24.24/l|
0d50  69 62 04 00 f0 1f 67 74  6b 2d 33 2e 73 6f 00 0e  |ibgtk-3.so..|
0d60  11 1f 07 02 12 23 12 24  0c 26 00 15 06 41 0b 40  |.#.$.&...A.@|
0d70  00 1d 11 20 26 1e 5b 2e  2e 2e 61 74 65 2f 77 78  |... &.[...ate/wx|
--8<---cut here---end--->8---

The referenced store item is this:

  /gnu/store/n2cnp2fivxq10kxqalcv2q41wzsyj9yd-gtk+-3.24.24

Notice that in the .zo file, there are three additional bytes inserted
before the dash ("-").

This store reference is seen by the Guix scanner, because the nix hash
is stored contiguously.  However, it is *not* seen by the grafter.

Note that the grafter assumes that the entire store item name will be
stored contiguously.  The current implementation only finds hashes that
are immediately followed by a dash ("-"), and moreover assumes that nix
hashes will never occur except within the corresponding store item name.

In this case, the reference was simply ignored, because the dash was
separated from the hash.  If the extra junk had been inserted *after*
the dash, the grafter would have made a mess of things.  It would have
(incorrectly) assumed that the rest of the expected store item name
followed the dash, and inappropriately written the replacement string
over the unexpected bytes.

With this case in mind, I think we can no longer safely assume that the
bytes following a nix hash will be as we expect.  As a general
principle, I think that *every* byte that the grafter modifies should
first be checked against its expected value.  That should allow us to
catch problems like this early, and avoid non-obvious breakage cropping
up.

What do you think?

  Mark

bug#47222: Serious bug in Nettle's ecdsa_verify

[Léo Le Bouter via Bug reports for GNU Guix]

I am no expert cryptographer, it is likely that if I try backporting
such patches I will get something wrong that introduces more flaws.

https://security-tracker.debian.org/tracker/CVE-2021-20305 - no patch
backported yet
https://packages.ubuntu.com/source/focal/nettle - no patch backported
either

It would be best if Nettle adopted a forever (or almost) backwards
compatible ABI from now on like curl (https://curl.se/libcurl/abi.html)
so that such things don't happen again.

Thank you,
Léo


signature.asc
Description: This is a digitally signed message part

bug#33848: Store references in SBCL-compiled code are "invisible"

[Mark H Weaver]

Here's a revised draft of the patch, which updates the comments and
refactors the code a bit to (hopefully) make it a bit more readable.

   Mark

>From 6eec36e66d20d82fe02c6de793422875477b90d8 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Fri, 2 Apr 2021 18:36:23 -0400
Subject: [PATCH] DRAFT: grafts: Support rewriting UTF-16 and UTF-32 store
 references.

* guix/build/graft.scm (replace-store-references): Add support for
finding and rewriting UTF-16 and UTF-32 store references.
* tests/grafts.scm: Add tests.
---
 guix/build/graft.scm | 247 +++
 tests/grafts.scm |  68 
 2 files changed, 224 insertions(+), 91 deletions(-)

diff --git a/guix/build/graft.scm b/guix/build/graft.scm
index c119ee71d1..23fca8f29c 100644
--- a/guix/build/graft.scm
+++ b/guix/build/graft.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015, 2016, 2018 Ludovic Courtès 
-;;; Copyright © 2016 Mark H Weaver 
+;;; Copyright © 2016, 2021 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -55,6 +55,40 @@
 (string->char-set "0123456789abcdfghijklmnpqrsvwxyz")
 <>))
 
+(define (nix-base32-char-or-nul? byte)
+  (or (nix-base32-char? byte)
+  (char=? byte #\nul)))
+
+(define (possible-utf16-hash? buffer i w)
+  (and (<= (* 2 hash-length) (- i w))
+   (let loop ((j (+ 1 (- i (* 2 hash-length)
+ (or (>= j i)
+ (and (zero? (bytevector-u8-ref buffer j))
+  (loop (+ j 2)))
+
+(define (possible-utf32-hash? buffer i w)
+  (and (<= (* 4 hash-length) (- i w))
+   (let loop ((j (+ 1 (- i (* 4 hash-length)
+ (or (>= j i)
+ (and (zero? (bytevector-u8-ref buffer j))
+  (zero? (bytevector-u8-ref buffer (+ j 1)))
+  (zero? (bytevector-u8-ref buffer (+ j 2)))
+  (loop (+ j 4)))
+
+(define (insert-nuls char-size bv)
+  (if (or (not bv) (= char-size 1))
+  bv
+  (let* ((len (bytevector-length bv))
+ (bv* (make-bytevector (+ 1 (* char-size
+   (- len 1)))
+   0)))
+(let loop ((i 0))
+  (when (< i len)
+(bytevector-u8-set! bv* (* i char-size)
+(bytevector-u8-ref bv i))
+(loop (+ i 1
+bv*)))
+
 (define* (replace-store-references input output replacement-table
#:optional (store (%store-directory)))
   "Read data from INPUT, replacing store references according to
@@ -76,9 +110,9 @@ bytevectors to the same value."
   (list->vector (map pred (iota 256)))
   <>))
 
-  (define nix-base32-byte?
+  (define nix-base32-byte-or-nul?
 (optimize-u8-predicate
- (compose nix-base32-char?
+ (compose nix-base32-char-or-nul?
   integer->char)))
 
   (define (dash? byte) (= byte 45))
@@ -86,100 +120,131 @@ bytevectors to the same value."
   (define request-size (expt 2 20))  ; 1 MiB
 
   ;; We scan the file for the following 33-byte pattern: 32 bytes of
-  ;; nix-base32 characters followed by a dash.  To accommodate large files,
-  ;; we do not read the entire file, but instead work on buffers of up to
-  ;; 'request-size' bytes.  To ensure that every 33-byte sequence appears
-  ;; entirely within exactly one buffer, adjacent buffers must overlap,
-  ;; i.e. they must share 32 byte positions.  We accomplish this by
-  ;; "ungetting" the last 32 bytes of each buffer before reading the next
-  ;; buffer, unless we know that we've reached the end-of-file.
+  ;; nix-base32 characters followed by a dash.  When we find such a pattern
+  ;; whose hash is in REPLACEMENT-TABLE, we perform the required rewrite and
+  ;; continue scanning.
+  ;;
+  ;; To support UTF-16 and UTF-32 store references, the 33 bytes comprising
+  ;; this hash+dash pattern may optionally be interspersed by extra NUL bytes.
+  ;; This simple approach works because the characters we are looking for are
+  ;; restricted to ASCII.  UTF-16 hashes are interspersed with single NUL
+  ;; bytes ("\0"), and UTF-32 hashes are interspersed with triplets of NULs
+  ;; ("\0\0\0").  Note that we require NULs to be present only *between* the
+  ;; other bytes, and not at either end, in order to be insensitive to byte
+  ;; order.
+  ;;
+  ;; To accommodate large files, we do not read the entire file at once, but
+  ;; instead work on buffers of up to 'request-size' bytes.  To ensure that
+  ;; every hash+dash pattern appears in its entirety in at least one buffer,
+  ;; adjacent buffers must overlap by one byte less than the maximum size of a
+  ;; hash+dash pattern.  We accomplish this by "ungetting" a suffix of each
+  ;; buffer before reading the next buffer, unless we know that we've reached
+  ;; the end-of-file.
   (let ((buffer (make-bytevector request-size)))
-(let loop ()
-  ;; Note: We avoid '

bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.

[Ludovic Courtès]

Hi Maxime,

Maxime Devos  skribis:

> On Mon, 2021-04-05 at 21:54 +0200, Ludovic Courtès wrote:
>> [...]
>> 
>> OK.  It does mean that the bug is hardly exploitable in practice: you
>> have to be able to log in at all,
> Yes.
>
>>  and if you’re able to log in, you have
>> to log in precisely within the 1s (or less) that follows account
>> creation, which sounds challenging (TCP + SSH connection establishment
>> is likely to take as much time or more,
>
> Is logging in possible when the home directory doesn't exist?

I think so.

> An attacker could copy and paste, or have used a single-character password,
> to save some time.

Hmm yes.  It’s a bit a far-fetched though: the attacker would have
passed the sysadmin the output of the ‘crypt’ procedure, such that the
sysadmin cannot know the password length.

>> Does it warrant as strong messaging as for the recent daemon
>> ‘--keep-failed’ vulnerability?
>
> As it is a one-time chance, with a limited window, and only under specific
> circumstances (creating a new user account), I don't think so.  But I would
> still recommend to upgrade.  Does the blog post have ‘too strong messaging’? 

The blog post and info-guix messages are the highest levels of
visibility we can give, roughly.  So I think we have to think twice
before doing that or truly important issues will eventually go
unnoticed.

The risk with this issue seems much lower than that of the keep-failed
issue, it even looks super low.

WDYT?

Ludo’.

bug#47260: Package GNU MediaGoblin as a Guix service

[Ben Sturmfels via Bug reports for GNU Guix]

On Thu, 01 Apr 2021, Ben Sturmfels wrote:

> 5. Get a basic Guix service working, with sqlite3 and without the
> offloaded media transcoding currently using Celery task queue with a
> Redis broker.

Woo! After a lot of trial and error, I finally have a basic MediaGoblin
running entirely under Guix with no virtualenv trickery!

After applying the attached patch to my guix repo, I grab a copy of the
basic config files and enable audio and video:

  curl 
https://git.savannah.gnu.org/cgit/mediagoblin.git/plain/mediagoblin.example.ini 
> mediagoblin.ini
  curl https://git.savannah.gnu.org/cgit/mediagoblin.git/plain/paste.ini > 
paste.ini
  echo "[[mediagoblin.media_types.audio]]" >> mediagoblin.ini
  echo "[[mediagoblin.media_types.video]]" >> mediagoblin.ini

Build MediaGoblin, which downloads from our master branch and runs the
full test suite successfully:

  ~/ws/guix/pre-inst-env guix build mediagoblin

Then install MediaGoblin in a container (not working in a non-container
guix environment or without explicit "python"):

  ~/ws/guix/pre-inst-env guix environment --container --network 
--share=$HOME/.bash_history --ad-hoc mediagoblin python

Create an sqlite3 database and add a user:

  gmg dbupdate
  gmg adduser --username admin --password a --email ad...@example.com
  gmg changepw admin a

Upload an image, audio and video via CLI:

  gmg addmedia admin image.jpg
  gmg addmedia admin audio.wav
  gmg addmedia admin video.mp4

Start the web interface:

  CELERY_ALWAYS_EAGER=true paster serve paste.ini

The web interface is working. Looks like we're missing some CSS
(probably due to files not being included in the setuptools package),
but that's a minor issue.

Getting there!

Regards,
Ben
>From 704cd6aa56f17d4f705d33f1f58ff03e2581a2da Mon Sep 17 00:00:00 2001
From: Ben Sturmfels 
Date: Tue, 6 Apr 2021 12:48:47 +1000
Subject: [PATCH] Add MediaGoblin package.

---
 gnu/local.mk |   1 +
 gnu/packages/mediagoblin.scm | 266 +++
 2 files changed, 267 insertions(+)
 create mode 100644 gnu/packages/mediagoblin.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index f2d595f2cc..b2daa3cfe6 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -467,6 +467,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/python-science.scm		\
   %D%/packages/python-web.scm			\
   %D%/packages/python-xyz.scm			\
+  %D%/packages/mediagoblin.scm			\
   %D%/packages/toys.scm\
   %D%/packages/tryton.scm			\
   %D%/packages/qt.scm\
diff --git a/gnu/packages/mediagoblin.scm b/gnu/packages/mediagoblin.scm
new file mode 100644
index 00..87649c965a
--- /dev/null
+++ b/gnu/packages/mediagoblin.scm
@@ -0,0 +1,266 @@
+;; Install with:
+;;
+;; ~/ws/guix/pre-inst-env guix environment --container --network --share=$HOME/.bash_history --ad-hoc mediagoblin
+;;
+;; Doesn't currently work when not in a container:
+;;
+;; ~/ws/guix/pre-inst-env guix environment --ad-hoc mediagoblin
+
+(define-module (gnu packages mediagoblin)
+  #:use-module (ice-9 match)
+  #:use-module (srfi srfi-1)
+  #:use-module (guix packages)
+  #:use-module (guix licenses)
+  #:use-module (guix download)
+  #:use-module (guix git-download)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix build-system python)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages xiph)  ; flac for embedded libsndfile
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages base)
+  #:use-module (gnu packages certs)
+  #:use-module (gnu packages check)
+  #:use-module (gnu packages compression)  ; unzip for embedded python-wtforms
+  #:use-module (gnu packages databases)
+  #:use-module (gnu packages libffi)  ; cffi for embedded python-soundfile
+  #:use-module (gnu packages openldap)
+  #:use-module (gnu packages pdf)
+  #:use-module (gnu packages pkg-config)  ; embedded libsndfile
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages python-crypto)
+  #:use-module (gnu packages python-web)
+  #:use-module (gnu packages python-xyz)
+  #:use-module (gnu packages sphinx)
+  #:use-module (gnu packages gstreamer)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages pulseaudio)
+  #:use-module (gnu packages rsync)
+  #:use-module (gnu packages ssh)
+  #:use-module (gnu packages time)
+  #:use-module (gnu packages video)
+  #:use-module (gnu packages version-control)
+  #:use-module (gnu packages xml)
+  #:use-module ((guix licenses) #:select (bsd-3 gpl2+) #:prefix license:))
+
+(define python-wtforms
+  (package
+(name "python-wtforms")
+(version "2.3.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "WTForms" version))
+   (sha256
+(base32
+ ;; Interesting, if this has is that of a lower version, it blindly
+ ;; ignores the version number above and you silently get the older
+ ;; version.
+ "17427m7p9nn9byzva697dkykykwcp2br3bxvi8vciywlmkh5s6c1"
+(build-system python-build-system)
+(arguments
+ `

bug#47260: Package GNU MediaGoblin as a Guix service

[Ben Sturmfels via Bug reports for GNU Guix]

On Mon, 05 Apr 2021, Léo Le Bouter wrote:

> On Tue, 2021-04-06 at 00:17 +1000, Ben Sturmfels wrote:
>> On Thu, 01 Apr 2021, Ben Sturmfels wrote:
>> 
>> > 7. Work out why H264 support is missing.
>> 
>> This is now fixed MediaGoblin's master branch guix-env.scm by adding
>> gst-libav to propagated inputs.
>
> Hello!
>
> I suggest not using propagated-inputs because they are likely to cause
> conflicts in profiles when used. I suggest intead creating wrapper
> scripts that append to the PATH variable.
>
> Examples of such wrapper scripts can be found:
>
> - 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=373e5fc96724fd38bb1263e4af90932ea36f596b
> (PYTHONPATH more so)
> - 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=00c1793ce8e2210e48b18422ea3e76da10541874
> (Append xdg-utils to PATH)
>
> Let me know if there's any questions about creating such wrappers.

Thanks Léo, I'll look into this!

Regards,
Ben

bug#47458: Terrible UX upgrading Emacs in Guix

[Maxim Cournoyer]

Hi Leo!

Leo Prikler  writes:

[...]

>> Shouldn't we wrap all the binaries to be on the safe side?  Things
>> such
>> as emacsclient probably ought to have EMACSLOADPATH set correctly,
>> no?
> The remaining binaries are
> - emacsclient, which inherits its EMACSLOADPATH from the server it
> connects to
> - ctags, ebrowse and etags, which are helper binaries, that don't seem
> to rely on EMACSLOADPATH at all.  (Or is there an indicator, that they
> do?)
> - .-real binaries, that should only be wrapped once.
> We could relax the regex to include the upper two, but I don't think
> it's necessary to do so.

OK, thanks for the explanation, it makes sense.

[...]

> I'd like to avoid pushing this to master just yet, because we also have
> changes in the Emacs build system to discuss and I don't want to cause
> an "Emacs world" rebuild twice in a row.  That said, I'm including this
> patch in wip-emacs with the plan to push to master or staging once
> everything there is resolved.

Sure!  Which changes do you have in mind?  Are they already on the
tracker for review?

Thank you,

Maxim

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Ludovic Courtès]

Hi,

For the record, changing ‘qt-build-system’ would trigger a rebuild of
less than 400 packages according to the back-of-the-envelope calculation
below.  In that case, it’s tempting to fix on ‘master’ and include it in
the release.

Thoughts?

Ludo’.

--8<---cut here---start->8---
scheme@(guile-user)> ,use(gnu)
scheme@(guile-user)> ,use(guix build-system qt)
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> (define qtpkgs (fold-packages (lambda (pkg lst)
 (if (eq? 
(package-build-system pkg) qt-build-system)
 (cons pkg lst)
 lst))
   '()))
scheme@(guile-user)> (length qtpkgs)
$78 = 186
scheme@(guile-user)> ,use(guix graph)
scheme@(guile-user)> ,run-in-store (node-edges (@ (guix scripts graph) 
%reverse-package-node-type) (fold-packages cons '()))
$79 = #
scheme@(guile-user)> (node-reachable-count qtpkgs $79)
$80 = 180
scheme@(guile-user)> (+ 186 180)
$81 = 366
--8<---cut here---end--->8---

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Efraim Flashner]

On Tue, Apr 06, 2021 at 03:17:52PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> For the record, changing ‘qt-build-system’ would trigger a rebuild of
> less than 400 packages according to the back-of-the-envelope calculation
> below.  In that case, it’s tempting to fix on ‘master’ and include it in
> the release.
> 
> Thoughts?
> 

There are a couple of other things we want to change with the
qt-build-system and the wrappers. Another one is changing the wrappers
so they prefix (or was it suffix?) QT_QPA_PLUGIN (and I think others) so
they can run natively on wayland. I think it would be a good
improvement and worth it.

> Ludo’.
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(gnu)
> scheme@(guile-user)> ,use(guix build-system qt)
> scheme@(guile-user)> ,use(guix)
> scheme@(guile-user)> (define qtpkgs (fold-packages (lambda (pkg lst)
>(if (eq? 
> (package-build-system pkg) qt-build-system)
>(cons pkg lst)
>lst))
>  '()))
> scheme@(guile-user)> (length qtpkgs)
> $78 = 186
> scheme@(guile-user)> ,use(guix graph)
> scheme@(guile-user)> ,run-in-store (node-edges (@ (guix scripts graph) 
> %reverse-package-node-type) (fold-packages cons '()))
> $79 = #
> scheme@(guile-user)> (node-reachable-count qtpkgs $79)
> $80 = 180
> scheme@(guile-user)> (+ 186 180)
> $81 = 366
> --8<---cut here---end--->8---
> 
> 
> 

-- 
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#47570: libvirt still embeds full path to qemu-system in saved .xml files

[Pierre Langlois]

divoplade writes:

> Le lundi 05 avril 2021 à 19:45 +0100, Pierre Langlois a écrit :
>> Do you know at which guix commit this happened?  I'm wondering which
>> version of libvirt triggered this.  AFAICT, right now, if you create
>> a
>> fresh VM using gnome-boxes, it initializes the xml config with the
>> qemu
>> in /run/current-system/profile, which looks like the right thing to
>> do.
>
> I think my system did not auto-upgrade for some time because of a bug
> in org-html-export-to-html that broke one of my packages (the bug is,
> there’s an explicit comment to indicate a license for a script and that
> comment is not XHTML). I don’t know which commit did that, but the
> faulty system was between that commit and 24h before. Or there was
> another earlier problem, and I can’t help, sorry.
>
> You’re right, now that I upgraded it’s fixed.

Cool :-), closing the bug then!

Thanks,
Pierre



signature.asc
Description: PGP signature

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Efraim Flashner]

On Tue, Apr 06, 2021 at 04:43:46PM +0300, Efraim Flashner wrote:
> On Tue, Apr 06, 2021 at 03:17:52PM +0200, Ludovic Courtès wrote:
> > Hi,
> > 
> > For the record, changing ‘qt-build-system’ would trigger a rebuild of
> > less than 400 packages according to the back-of-the-envelope calculation
> > below.  In that case, it’s tempting to fix on ‘master’ and include it in
> > the release.
> > 
> > Thoughts?
> > 
> 
> There are a couple of other things we want to change with the
> qt-build-system and the wrappers. Another one is changing the wrappers
> so they prefix (or was it suffix?) QT_QPA_PLUGIN (and I think others) so
> they can run natively on wayland. I think it would be a good
> improvement and worth it.

A quick search pulls up the following bugs: 43446 44982 45193 45221 45784.
Looks like there's a lot of desire to see it adjusted.

> > Ludo’.
> > 
> > --8<---cut here---start->8---
> > scheme@(guile-user)> ,use(gnu)
> > scheme@(guile-user)> ,use(guix build-system qt)
> > scheme@(guile-user)> ,use(guix)
> > scheme@(guile-user)> (define qtpkgs (fold-packages (lambda (pkg lst)
> >  (if (eq? 
> > (package-build-system pkg) qt-build-system)
> >  (cons pkg lst)
> >  lst))
> >'()))
> > scheme@(guile-user)> (length qtpkgs)
> > $78 = 186
> > scheme@(guile-user)> ,use(guix graph)
> > scheme@(guile-user)> ,run-in-store (node-edges (@ (guix scripts graph) 
> > %reverse-package-node-type) (fold-packages cons '()))
> > $79 = #
> > scheme@(guile-user)> (node-reachable-count qtpkgs $79)
> > $80 = 180
> > scheme@(guile-user)> (+ 186 180)
> > $81 = 366
> > --8<---cut here---end--->8---
> > 
> > 
> > 
> 
> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted



-- 
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#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Maxim Cournoyer]

Hi Leo et al.,

Leo Famulari  writes:

> On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
>> I see now that I'm using an older version, although I would have
>> preferred the newer one.  I refer to the variable name 'inkscape' from
>> my manifest file, and I expected that to point to the latest stable
>> version.  However, it seems that one must use the 'inkscape-1.0'
>> variable to get the latest stable version.  That's seems suboptimal.
>> 
>> I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
>> (for use in packages such as 'dblatex/stable'), and then 'inkscape'
>> could be repurposed to point to the latest stable version.  Thoughts?
>
> I think we should do this, or even remove the old Inkscape package now.
>
> I'm guessing the reason for keeping the older release series is that
> the Inkscape save-file format changed?

The reason inksape@0.92 is still kept around is becauseInkscape@1
doesn't build on ARM (more accurately, one of its dependencies,
lib2geom, doesn't).  It's been a while since I looked at the issue, and
it seems there may have been some activity in lib2geom upstream to try
to address the problem, so we should revisit it.

Maxim

bug#47617: Docker containers retain references to the runc used

[Maxim Cournoyer]

Hello Guix!

I had this surprise today, after reconfiguring my Guix System with an
upgraded docker:

Upon attempting to run an existing container created with the previous
Docker version, I got:

--8<---cut here---start->8---
ERROR: for moodle-docker_db_1  Cannot start service db: Unknown runtime 
specified /gnu/store/jx64b4nnh6yvsbp117bfjc5spqz0jfq5-runc-1.0.0-rc6/sbin/runc
--8<---cut here---end--->8---

It seems the containers retain the exact references to the runc used,
and it somehow cause the execution to fail when it doesn't match with
the runc that the current Docker program is using.

The workaround is to destroy the containers and recreate them from
scratch on this upgraded Docker instance.

Thanks,

Maxim

bug#47618: "guix upgrade" and "guix package -u ." inconsistency

[Brendan Tildesley via Bug reports for GNU Guix]

Below, --do-not-upgrade appears to be behaving like "--only-upgrade". I realised
this comes about because I didn't use '='. guix upgrade takes all other
arguments to be upgrade regex's, but it still seems. _wrong_.  Some long
arguments in guix require and = sign after them, and the cli help indicates as
much, but --do-not-upgrade seems to break that pattern and takes all arguments
after it to be regexes's to match and not upgrade.  flags that have this
behaviour of acting on all arguments after them should indicate clearly they do
that. and indicated if the '=' is optional using some intuitive notation.
The line:

--do-not-upgrade[=REGEXP] do not upgrade any packages matching REGEXP

suggest it must take either no argument or only '=something'.

guix upgrade --help says that it is an alias for 'guix package -u .'. My
understanding is that the meaning of alias is something that can be substituted
and it will behave the same, like Bash aliases.  We should change 'guix
upgrade''s behaviour to be like 'guix package -u', taking all arguments after
--do-not-upgrade as regex's to not upgrade.


b@jiu ~/code/guix [env]$ guix upgrade --do-not-upgrade '^[a-n]'
The following packages will be upgraded:
audacity  (dependencies or package changed)
cool-retro-term   (dependencies or package changed)
deluge(dependencies or package changed)
diffoscope170 → 171
emacs (dependencies or package changed)
eog   (dependencies or package changed)
evince(dependencies or package changed)
ffmpeg(dependencies or package changed)
git   2.31.0 → 2.31.1
git:send-email2.31.0 → 2.31.1
gnome-font-viewer (dependencies or package changed)
gnome-tweaks  (dependencies or package changed)
godot (dependencies or package changed)
ibus  (dependencies or package changed)
ibus-anthy(dependencies or package changed)
icecat(dependencies or package changed)
keepassxc (dependencies or package changed)
lm-sensors(dependencies or package changed)
lollypop  (dependencies or package changed)
mpv   (dependencies or package changed)
mumble(dependencies or package changed)

62.6 MB will be downloaded
^C
b@jiu ~/code/guix [env]$ guix package -u . --do-not-upgrade '^[a-n]'
The following packages will be upgraded:
obs(dependencies or package changed)
piper  (dependencies or package changed)
playonlinux(dependencies or package changed)
rhythmbox  (dependencies or package changed)
stellarium (dependencies or package changed)
syncthing-gtk  (dependencies or package changed)
tinc   (dependencies or package changed)
transmission:gui   (dependencies or package changed)
ungoogled-chromium (dependencies or package changed)
vlc(dependencies or package changed)
youtube-dl (dependencies or package changed)
zrythm (dependencies or package changed)

The following derivation will be built:
/gnu/store/6ldzv7ilcsg4ah8vyig9vyh9y79yz6m1-tinc-1.1pre17.drv

bug#47458: Terrible UX upgrading Emacs in Guix

[Leo Prikler]

Hi Maxim!

Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
> Hi Leo!
> 
> Leo Prikler  writes:
> 
> [...]
> 
> > > Shouldn't we wrap all the binaries to be on the safe
> > > side?  Things
> > > such
> > > as emacsclient probably ought to have EMACSLOADPATH set
> > > correctly,
> > > no?
> > The remaining binaries are
> > - emacsclient, which inherits its EMACSLOADPATH from the server it
> > connects to
> > - ctags, ebrowse and etags, which are helper binaries, that don't
> > seem
> > to rely on EMACSLOADPATH at all.  (Or is there an indicator, that
> > they
> > do?)
> > - .-real binaries, that should only be wrapped once.
> > We could relax the regex to include the upper two, but I don't
> > think
> > it's necessary to do so.
> 
> OK, thanks for the explanation, it makes sense.
> 
Should I also document that (as a comment in the code) or is it
somewhat intuitive, that only Emacs is interested in these variables
(just EMACSLOADPATH currently, maybe also PATH later)?
> 
> > I'd like to avoid pushing this to master just yet, because we also
> > have
> > changes in the Emacs build system to discuss and I don't want to
> > cause
> > an "Emacs world" rebuild twice in a row.  That said, I'm including
> > this
> > patch in wip-emacs with the plan to push to master or staging once
> > everything there is resolved.
> 
> Sure!  Which changes do you have in mind?  Are they already on the
> tracker for review?
> 

I've sent some of the changes for emacs-build-system to 45316.  The
rest only lives on wip-emacs as of yet.  The first 5 patches on that
branch are the ones that include the big changes (well, four of them
anyway), one of which is not yet up to review as it results from the
combined fixes to 45316 and 47458, the rest are mostly small "fixup"
commits.

Regards,
Leo

bug#47622: vigra package is vulnerable to CVE-2021-30046

[Léo Le Bouter via Bug reports for GNU Guix]

CVE-2021-30046  15:15
VIGRA Computer Vision Library Version-1-11-1 contains a segmentation
fault vulnerability in the impex.hxx read_image_band() function, in
which a crafted file can cause a denial of service.

Upstream issue: https://github.com/ukoethe/vigra/issues/494

No fix provided yet.


signature.asc
Description: This is a digitally signed message part

bug#33848: Store references in SBCL-compiled code are "invisible"

[Leo Famulari]

On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Courtès wrote:
> The GC’s scanner still gets it wrong though.  I wonder whether having
> the grafting code more capable than the scanner could lead to bad
> surprises.  WDYT?

I'm going off-topic, but I've wished we had a generic fast string-search
(and replace?) procedure.

The go-build-system has a slow "one byte a time" implementation because
I couldn't figure out how to re-use the code in (guix build grafts):

https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/go-build-system.scm?h=v1.2.0#n269

There are probably some other places we could use a fast procedure. It
might even be something to add to Guile.

bug#47614: [security] Chunked store references in .zo files in Racket 8

[Léo Le Bouter via Bug reports for GNU Guix]

I think that probably replacing arbitrary paths in built binaries is a
risky and maybe unreliable engineering choice and that mechanisms
inside kernels should be preferred to give processes a different view
of the file system (retaining the path but changing the contents of the
folder).

OTOH, what would be wrong with replacing hashes directly without
expecting them to be next to anything else?

Léo


signature.asc
Description: This is a digitally signed message part

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Ludovic Courtès]

Hi again!

The attached patch fixes this problem AFAICS by filtering out of
XDG_DATA_DIRS directories that are unlikely to be of any use.  It
follows the same strategy as ‘glib-or-gtk-build-system’, which is to
only include share/ sub-directories that also contain one of the given
“selectors”: /glib-2.0/schemas, /sounds, /themes, etc.

It gives me a working ktouch, with a wrapper sets a much shorter
XDG_DATA_DIR:

--8<---cut here---start->8---
$ head -2 $(./pre-inst-env guix build --no-grafts ktouch)/bin/ktouch
#!/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
export 
XDG_DATA_DIRS="/gnu/store/mgzijzw7yn03pbk54zy0f81gyph9jh3k-ktouch-20.12.1/share:/gnu/store/5g95qdh0p46qszv199rmdd2lx4mninm7-kcoreaddons-5.70.0/share"
$ head -2 $(guix build --no-grafts ktouch)/bin/ktouch
#!/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
export 
XDG_DATA_DIRS="/gnu/store/f821syw55jd0l04xkmnbvp562flrw6fm-ktouch-20.12.1/share:/gnu/store/3dsl2jalrcyldkrsqab1hc6sv8pyag9z-cmake-minimal-3.16.5/share:/gnu/store/3x63j4ndhbzkjwr6mhnp4h86r550gs7q-extra-cmake-modules-5.70.0/share:/gnu/store/w08sglxbfpmcvz25pfgnq7v27m1rlkf9-kdoctools-5.70.0/share:/gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/share:/gnu/store/v6f44zccwh9z5zk3pjlywjybbi8n2hjh-tar-1.32/share:/gnu/store/ncydgq2znms5n1d2k5yqshhf58nsixwv-gzip-1.10/share:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/share:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/share:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/share:/gnu/store/n4n560pfvvw50a9369axw5vj5rrqfj1n-diffutils-3.7/share:/gnu/store/cd5qf3kcnlq35p9k392pjdpdzpsnds70-patch-2.7.6/share:/gnu/store/hic7snhayfl7m6cpfqqr73nmm19bpqkg-findutils-4.7.0/share:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/share:/gnu/store/ishk7fswcs4gkwcp8mh788z4mvvl9bxh-sed-4.8/share:/gnu/store/bhs4rj58v8j1narb2454raan2ps38xd8-grep-3.4/share:/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/share:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/share:/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/share:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/share:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/share:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/share:/gnu/store/s3dcqzwqaakv1yx37by9chksdbkgih17-glibc-2.31-static/share:/gnu/store/5rj71g09qc9g20mv0lh5a28jhwa5d6dl-kcmutils-5.70.0/share:/gnu/store/3vdmy5gjn1a23ky6l907byc3917xfh2a-kcompletion-5.70.0/share:/gnu/store/ba8nl7wflsf1s95x72kpaj0rzval908b-kconfig-5.70.0/share:/gnu/store/r4120j3v7cnv5qlmp2kqb6xbc63gplpa-kconfigwidgets-5.70.0/share:/gnu/store/5g95qdh0p46qszv199rmdd2lx4mninm7-kcoreaddons-5.70.0/share:/gnu/store/lbq73h2snwpn4wf9wkp8j0rxw0lyhyp4-kdeclarative-5.70.0/share:/gnu/store/k4k0mrgv31clkpl38zjnpb3l0nin2nnl-ki18n-5.70.0/share:/gnu/store/agmzjiqcv1lb77jmr7xwx0br4sy12i6d-kiconthemes-5.70.0/share:/gnu/store/0mbm58p5mybimbvv8ainkzz7mdpynd25-kitemviews-5.70.0/share:/gnu/store/yqpk8haa1z5plgb134f95vryjxghlyjv-kqtquickcharts-20.04.1/share:/gnu/store/5mfz0faj9lc9m1ppijgqkxz03j89dyil-ktextwidgets-5.70.0/share:/gnu/store/fwmp85k5hqy7fw0rnq5560pg4amiblz4-kwidgetsaddons-5.70.0/share:/gnu/store/xslnsy6sxjp66l99mvj67v1x30bh55xi-kwindowsystem-5.70.0/share:/gnu/store/n79ns6y3cc7ny4mkp5qidf57j1cxbg6p-kxmlgui-5.70.0/share:/gnu/store/3x6y8kpbwjmzpndjfhdbn654g7dm85cp-libxcb-1.14/share:/gnu/store/zc9bpa1v46cnqc05xk8njm08bwk8a70m-libxkbfile-1.1.0/share:/gnu/store/j7110r2rhs9pdypx2x0h8nx4r082fbdk-qtbase-5.15.2/share:/gnu/store/8r5y5bnblc4s6w8j5sfxv06ra6lz12j8-qtdeclarative-5.15.2/share:/gnu/store/c020rcd650ikq7gqfnkga46kzis3v2hi-qtgraphicaleffects-5.15.2/share:/gnu/store/2iwman5hbgg15r99rshl6lsxz35dq2b2-qtquickcontrols2-5.15.2/share:/gnu/store/n7dbg5cgcpslrym4zmsimps1ch1p0q8w-qtx11extras-5.15.2/share:/gnu/store/7yjd1h08li3dr2188pfwfnwlq0p3av9p-qtxmlpatterns-5.15.2/share:/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libre-headers-5.4.20/share:/gnu/store/kvdrfyi50zsmy0ykmc9p8qzjlahqfa4p-kservice-5.70.0/share:/gnu/store/yk425lbm0wnjpqm1z964l9l6li5x0wbn-kcodecs-5.70.0/share:/gnu/store/2z5nfmzxhqaalcrswp8nn3yk5ys8q261-kauth-5.70.0/share:/gnu/store/vhmyxywsdy92bgqxy6fnmcpr81xsfcys-kpackage-5.70.0/share:/gnu/store/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2/share:/gnu/store/n9wx4dp68bfsw9bb1bwmklzl34ggrmgm-gettext-minimal-0.20.1/share:/gnu/store/yqs5mkp20m58sr744cs2pn8sqb5m59sq-sonnet-5.70.0/share:/gnu/store/6cdl970wcv4jhvpgbh8sdj54a5gwhmwj-libxdmcp-1.1.3/share:/gnu/store/h7sy4hr7arjknbyy1aq0xwv6fksnzw9n-libxau-1.0.9/share:/gnu/store/klk98l8czl05lvanrr7xl7a9hksac4ak-libpthread-stubs-0.4/share:/gnu/store/k30a2pgmc6b3ifmq3rn0dr5ng9gr8w81-which-2.21/share:/gnu/store/7disnxqw8i3n4zhw5s0xj9kkdckkmr1p-mesa-20.2.4/share:/gnu/store/wxl57nkbqgamfp73b7v62kk3f1hiv0cz-xorgproto-2019.2/share:/gnu/store/c3zbbynb590yxrpwcxrkll80mn66h3kf-libxxf86vm-1.1.4/share:/gnu/store/jwga98k68l0h5c45jx7z4jdjzhfc34vm-libxshmfence-1.3/share:/gnu/store/9z9gd76la

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Leo Famulari]

On Tue, Apr 06, 2021 at 03:17:52PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> For the record, changing ‘qt-build-system’ would trigger a rebuild of
> less than 400 packages according to the back-of-the-envelope calculation
> below.  In that case, it’s tempting to fix on ‘master’ and include it in
> the release.
> 
> Thoughts?

Let's do it.

After the release, I think we should reconsider those numbers. Compared
to when we set those guidelines, we have a lot more packages and a lot
more computing power.

bug#47486: runc: hash mismatch

[Maxim Cournoyer]

Hello Simon,

zimoun  writes:

> Hi,
>
> Using Guix 55685e4, I get:
>
> $ guix build -S --no-substitutes runc
> The following derivations will be built:
>/gnu/store/19iqvzkdx514xm8hs5sn2clcn5pvfswm-runc-1.0.0-rc6.tar.xz.drv
>/gnu/store/ml7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv
> building 
> /gnu/store/ml7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv...
>
> Starting download of
> /gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz
>>From 
>>https://github.com/opencontainers/runc/releases/download/v1.0.0-rc6/runc.tar.xz...
> following redirection to
> `https://github-releases.githubusercontent.com/36960321/fe863f80-d2a1-11ea-908b-c3f145ce2ec0?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210329%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210329T204903Z&X-Amz-Expires=300&X-Amz-Signature=da77301e6f45dbdb8f5e540abb05fff40c15fd6a5688ae365694b5584183956c&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=36960321&response-content-disposition=attachment%3B%20filename%3Drunc.tar.xz&response-content-type=application%2Foctet-stream'...
> downloading from
> https://github.com/opencontainers/runc/releases/download/v1.0.0-rc6/runc.tar.xz
> ...
>  runc.tar.xz  528KiB 33.4MiB/s 00:00 [##] 
> 100.0%
> sha256 hash mismatch for
> /gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz:
>   expected hash: 1c7832dq70slkjh8qp2civ1wxhhdd2hrx84pq7db1mmqc9fdr3cc
>   actual hash:   05i1j4xqwnva30c24gcrdvdx6wcjqgpyz7cn3gi0bs6jlcfv43gs
> hash mismatch for store item
> '/gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz'
> build of /gnu/store/ml7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv
> failed
> View build log at
> '/var/log/guix/drvs/ml/7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv.bz2'.
> cannot build derivation
> `/gnu/store/19iqvzkdx514xm8hs5sn2clcn5pvfswm-runc-1.0.0-rc6.tar.xz.drv':
> 1 dependencies couldn't be built
> guix build: error: build of
> `/gnu/store/19iqvzkdx514xm8hs5sn2clcn5pvfswm-runc-1.0.0-rc6.tar.xz.drv'
> failed

Indeed it has change!  I've reported it upstream here:
https://github.com/opencontainers/runc/issues/2895.  To learn about what
changed, I ran the following commands:

--8<---cut here---start->8---
$ wget 
https://ci.guix.gnu.org/file/runc-1.0.0-rc6.tar.xz/sha256/1c7832dq70slkjh8qp2civ1wxhhdd2hrx84pq7db1mmqc9fdr3cc
 -O old.tar.xz

$ wget 
https://github.com/opencontainers/runc/releases/download/v1.0.0-rc6/runc.tar.xz 
-O new.tar.xz

$ diffoscope old.tar.xz new.tar.xz
--8<---cut here---end--->8---

And found that a slash went missing (weird):

[...]
│ │┄ Files identical despite different names
│ │   --- runc-1.0.0-rc6/vendor/golang.org/x/sys/windows/service.go
│ ├── +++ runc-1.0.0-rc6vendor/golang.org/x/sys/windows/service.go
│ │┄ Files identical despite different names
│ │   --- runc-1.0.0-rc6/vendor/golang.org/x/sys/windows/syscall.go
│ ├── +++ runc-1.0.0-rc6vendor/golang.org/x/sys/windows/syscall.go
│ │┄ Files identical despite different names
│ │   --- runc-1.0.0-rc6/vendor/golang.org/x/sys/windows/syscall_windows.go
│ ├── +++ runc-1.0.0-rc6vendor/golang.org/x/sys/windows/syscall_windows.go
│ │┄ Files identical despite different names
│ │   --- runc-1.0.0-rc6/vendor/golang.org/x/sys/windows/types_windows.go
│ ├── +++ runc-1.0.0-rc6vendor/golang.org/x/sys/windows/types_windows.go
│ │┄ Files identical despite different names
│ │   --- runc-1.0.0-rc6/vendor/golang.org/x/sys/windows/zsyscall_windows.go
│ ├── +++ runc-1.0.0-rc6vendor/golang.org/x/sys/windows/zsyscall_windows.go
│ │┄ Files identical despite different names

Note that I recently updated the package to v1.0.0-rc93.

Thanks for the report!

Closing.

Maxim

bug#47624: Various IP handling perl packages may be vulnerable

[Léo Le Bouter via Bug reports for GNU Guix]

Read: 
https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/

I have not had time to investigate deeply, posting here so the info is
not lost. I have already fixed one issue related to perl-data-validate-
ip in 8ec03ed5475ca7919a7d11541ff8cbf33a9ffe67, but it seems there's
several others.

One as CVE recently:

CVE-2021-29424  18:15
The Net::Netmask module before 2. for Perl does not properly
consider extraneous zero characters at the beginning of an IP address
string, which (in some situations) allows attackers to bypass access
control that is based on IP addresses.

Can't find a corresponding package in GNU Guix.

To be continued!
Léo


signature.asc
Description: This is a digitally signed message part

bug#43388: sxiv gif support is not working

[bdju]

September 14, 2020 1:36 AM, "Timotej Lazar"  wrote:
> I tried [1] and it works with `sxiv -a` here. What does `file
> picture.gif` say for your file?
Thank you for pointing me in the right direction. I had an mp4 named as
a gif! mpv could play it as-is, so I thought sxiv was to blame. Consider
this issue solved (or rather not a real bug).
Apologies for the delay, I've got my email filters set up wrong and
replies to my issues seem to skip my inbox. I've just searched my
bug-guix folder for my handle and found a lot of stuff now.

bug#43493: zathura (document reader) package missing .desktop file

[bdju]

On Mon Sep 21, 2020 at 2:22 AM CDT, Efraim Flashner wrote:
> On Thu, Sep 17, 2020 at 11:36:21PM -0500, bdju via Bug reports for GNU
> Guix wrote:
> > My PDFs are opening in GIMP! I went to fix it, but it seems I don't have
> > a generated zathura.desktop file.
> > guix (GNU Guix) 679d5e6b3dcac4ee1f419c04b3719fead0bd9ee5
>
> It looks like there's a .desktop file but it's named
> org.pwmt.zathura.desktop. Does that work?
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received
> unencrypted
Yes, that works! Thank you.

bug#43710: missing debug symbols for dino dependencies

[bdju]

On Fri Oct 2, 2020 at 3:50 PM CDT, Ludovic Courtès wrote:
> Hi bdju,
>
> "bdju"  skribis:
>
> > It seems just the debug symbols for dino weren't quite enough to get
> > good info. I also need debug symbols for the other dependencies. For
> > sure glib or libglib, whichever it is. If there are other dependencies
> > that could have debug output enabled, that would probably be helpful as
> > well.
>
> Indeed, not all packages come with debugging symbols, as explained at:
>
> https://guix.gnu.org/manual/en/html_node/Installing-Debugging-Files.html
>
> However, I think this bug report is not actionable from the maintainer
> perspective: we’re not going to enable debugging symbols on dino’s
> dependencies (118 packages according to ‘guix graph -t references
> dino’)
> just because one person needs to debug it.
>
> That said, I agree it would be nice to have debugging symbols on key
> packages such as GLib and/or to provide a simple way to obtain them
> (I’m
> thinking of a package transformation option.) That will take some more
> time.
>
> I’m closing this bug but feel free to open more specific issues.
>
> Thanks,
> Ludo’.
Sounds fair. (looks like this wasn't closed, I'll try to close it now)

bug#47614: [security] Chunked store references in .zo files in Racket 8

[Mark H Weaver]

Hi Léo,

Léo Le Bouter  writes:

> I think that probably replacing arbitrary paths in built binaries is a
> risky and maybe unreliable engineering choice and that mechanisms
> inside kernels should be preferred to give processes a different view
> of the file system (retaining the path but changing the contents of the
> folder).

I've had thoughts along these lines myself, but I don't think it can
work properly.  The fundamental problem is that in general, each process
includes shared objects from many different Guix packages.  There would
need to be a mechanism to determine, when looking up a file, which Guix
package that file lookup was originating from (or whether it was coming
from a file name provided by the user), in order to determine which
"view of the file system" to use for purposes of that lookup.  There's
no way to determine this reliably.

For example, when Emacs stats a file, there's no way to automatically
determine which view of the file system to use for that file lookup.  If
the file being stat'd is a file that the user asked to look at, it
should use the user's view of the file system.  If Emacs is trying to
load one of its own dependent libraries, it should see the file system
view associated with the dependencies of Emacs.  If some code in
GnuTLS's shared library (loaded by Emacs) performs a file lookup, it
should see the GnuTLS file system view.  See the problem?

I've come to think that the Guix approach is the most "correct"
approach, given the APIs that our existing body of software was written
for.  (If we rewrote our software from scratch with different APIs, we
would have more options here, but that would be crazy :)

> OTOH, what would be wrong with replacing hashes directly without
> expecting them to be next to anything else?

Personally, I would find that limitation acceptable, and that's fairly
close to what our grafter originally did (although my fast grafting code
always assumed that a "-" would follow the hash).  However, we've since
become accustomed to being able to have replacements with different
version numbers.  That's a nice feature.

Anyway, I doubt that imposing such a limitation would adequately solve
the problem here of chunked references in Racket 8, because I suspect
that Racket 8 could split store references at arbitrary points in the
string.  I doubt that we can safely assume that the hash component of
store references will be stored contiguously in *.zo files.

What do you think?

  Thanks,
Mark

bug#47225: QEMU warning about performance

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> While using `guix system vm`, I noticed this warning. I think it's new,
> maybe from the 5.2.0 update?
>
> --
> qemu-system-x86_64: warning: 9p: degraded performance: a reasonable
> high msize should be chosen on client/guest side (chosen msize is <=
> 8192). See https://wiki.qemu.org/Documentation/9psetup#msize for
> details.
> --
>
> That web page suggests that we increase the virtio packet size when
> declaring the 9p file-systems, I think in %linux-vm-file-systems of (gnu
> system vm).

The attached patch should fix it (it does for me at least!).

>From c720e68229322e5c38c0321b021e8d6430636111 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Tue, 6 Apr 2021 17:37:33 -0400
Subject: [PATCH] system: vm: Set a larger value for the msize option of the 9p
 file system.

Fixes .

* gnu/system/vm.scm (mapping->file-system): Set the msize option to a value of
100 MiB (from the default 8 KiB).

Reported-by: Leo Famulari 
---
 gnu/system/vm.scm | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 3d0935b3af..f9cf39ae42 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -581,7 +581,15 @@ the operating system."
(type "9p")
(flags (if writable? '() '(read-only)))
(options (string-append "trans=virtio"
-   (if writable? "" ",cache=loose")))
+   (if writable? "" ",cache=loose")
+   ;; By default, the msize value is 8 KiB, which
+   ;; according to QEMU is insufficient and would
+   ;; degrade performance.  The msize value should
+   ;; roughly match the bandwidth of the system's
+   ;; IO (see:
+   ;; https://wiki.qemu.org/Documentation/9psetup#msize).
+   ;; Use 100 MiB as a conservative default.
+   ",msize=104857600"))
(check? #f)
(create-mount-point? #t)
 
-- 
2.31.1


Thank you for the report,

Maxim

bug#45179: qutebrowser stuck at Cloudflare 'browser checks'

[bdju]

On Tue Dec 22, 2020 at 10:34 AM CST, Michael Rohleder wrote:
> Hello bdju,
>
> "bdju"  writes:
> > guix (GNU Guix) 91e35e32a4938e0e37499c64fa8ed3e7cf51dce3
> > some example sites with browser checks:
> > https://gitlab.com/users/sign_in
> > http://livechart.me/
> >
> > I already contacted the people in the qutebrowser IRC. The bug persists
> > when I launch with no config (`qutebrowser --temp-basedir'), and they
> > could not reproduce the issue on the same version of qutebrowser I'm
> > using. I suspect it may be an issue with the guix version.
> >
>
> A workaround is setting the "User Agent" string to something CF likes,
> e.g. like this:
> qutebrowser --temp-basedir --set content.headers.user_agent 'Mozilla/5.0
> (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0'
> https://gitlab.com/users/sign_in
>
> Maybe the reason why the (very helpful) #qutebrowser folks can't
> reproduce this, is because they use another qt version (qutebrowser uses
> qtwebengine) and perhaps this sets user agent to a string that CF has
> whitelisted.
>
> I don't think there is much we could do here (besides updating qt and
> mbakke has that in the pipeline, afaik).
>
> --
> COFFEE.EXE Missing - Insert Cup and Press Any Key
While I was able to bypass the cloudflare checks in IceCat with that
User Agent Switcher addon, I found I so far haven't been able to get
past them in qutebrowser by changing my useragent. I tried both your
example and copying one of the useragents generated by UAS in IceCat.
Still caught in a loop. (and I am using --temp-basedir as you said, so
shouldn't be my config)

bug#45179: qutebrowser stuck at Cloudflare 'browser checks'

[bdju]

On Tue Apr 6, 2021 at 4:41 PM CDT, bdju wrote:
> While I was able to bypass the cloudflare checks in IceCat with that
> User Agent Switcher addon, I found I so far haven't been able to get
> past them in qutebrowser by changing my useragent. I tried both your
> example and copying one of the useragents generated by UAS in IceCat.
> Still caught in a loop. (and I am using --temp-basedir as you said, so
> shouldn't be my config)
I was too hasty! I both had to change my useragent and wait a long time!
I didn't measure the time, but I'd guess over 10 minutes for Gitlab to
work. Livechart took even longer. Thanks so much for this workaround.
Oh, and this works without --temp-basedir, by the way. I should be able
to actually use these sites in my normal session now I think!

bug#47225: QEMU warning about performance

[Leo Famulari]

On Tue, Apr 06, 2021 at 05:42:15PM -0400, Maxim Cournoyer wrote:
> From c720e68229322e5c38c0321b021e8d6430636111 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Tue, 6 Apr 2021 17:37:33 -0400
> Subject: [PATCH] system: vm: Set a larger value for the msize option of the 9p
>  file system.
> 
> Fixes .
> 
> * gnu/system/vm.scm (mapping->file-system): Set the msize option to a value of
> 100 MiB (from the default 8 KiB).
> 
> Reported-by: Leo Famulari 

Thanks! I'll test and push along with the next kernel update (that's
when I noticed this warning). Feel free to push sooner if you like.

bug#47614: [security] Chunked store references in .zo files in Racket 8

[Léo Le Bouter via Bug reports for GNU Guix]

On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
> Hi Léo,
> 
> Léo Le Bouter  writes:
> 
> > I think that probably replacing arbitrary paths in built binaries
> > is a
> > risky and maybe unreliable engineering choice and that mechanisms
> > inside kernels should be preferred to give processes a different
> > view
> > of the file system (retaining the path but changing the contents of
> > the
> > folder).
> 
> I've had thoughts along these lines myself, but I don't think it can
> work properly.  The fundamental problem is that in general, each
> process
> includes shared objects from many different Guix packages.  There
> would
> need to be a mechanism to determine, when looking up a file, which
> Guix
> package that file lookup was originating from (or whether it was
> coming
> from a file name provided by the user), in order to determine which
> "view of the file system" to use for purposes of that
> lookup.  There's
> no way to determine this reliably.

Is it really that big a deal if it's impossible to access the ungrafted
/gnu/store item? If really required we could document a way to disable
it temporarily maybe? Do we need a specific view for each and every
package? I am thinking that overriding the view to the store item
that's a result of a package with a replacement field globally would be
sufficient.

> > OTOH, what would be wrong with replacing hashes directly without
> > expecting them to be next to anything else?
> 
> Personally, I would find that limitation acceptable, and that's
> fairly
> close to what our grafter originally did (although my fast grafting
> code
> always assumed that a "-" would follow the hash).  However, we've
> since
> become accustomed to being able to have replacements with different
> version numbers.  That's a nice feature.
> 

Version numbers, agree, I didnt realize that replacing the program name
and version was also required there. However I am thinking we could
fake (or alias, with a symlink) the version in the store item name on
purpose so that it remains the same while pointing to something with a
newer version, it would actually be better that way because we wouldnt
have to think about retaining identical version string length during
grafts.

> Anyway, I doubt that imposing such a limitation would adequately
> solve
> the problem here of chunked references in Racket 8, because I suspect
> that Racket 8 could split store references at arbitrary points in the
> string.  I doubt that we can safely assume that the hash component of
> store references will be stored contiguously in *.zo files.

Indeed, is the format for the string references in .zo files documented
anywhere? Is there hope you think we can recognize and automatically
rewrite these strings?

Thanks,
Léo


signature.asc
Description: This is a digitally signed message part

bug#47627: syncthing package is vulnerable to CVE-2021-21404

[Léo Le Bouter via Bug reports for GNU Guix]

CVE-2021-21404  06.04.21 22:15
Syncthing is a continuous file synchronization program. In Syncthing
before version 1.15.0, the relay server `strelaysrv` can be caused to
crash and exit by sending a relay message with a negative length field.
Similarly, Syncthing itself can crash for the same reason if given a
malformed message from a malicious relay server when attempting to join
the relay. Relay joins are essentially random (from a subset of low
latency relays) and Syncthing will by default restart when crashing, at
which point it's likely to pick another non-malicious relay. This flaw
is fixed in version 1.15.0.

We still ship 1.5.0, we crucially need to update that *very* useful
networked daemon package. With the new go importer maybe that's easier.
Also work in the go build system needs to happen IIRC.

Previous discussion about updating syncthing: 
https://issues.guix.gnu.org/45476

Léo


signature.asc
Description: This is a digitally signed message part

bug#47628: Epiphany fails to launch after webkitgtk-2.32.0 update

[Mark H Weaver]

FYI, since updating to webkitgtk-2.32.0 (commit
3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no
window appears, although GNOME Shell shows an empty outline in overview
mode, as if there's a window but it has never been painted.

When running 'epiphany' from the command line, I see the followin
warning from 'bwrap', which indicates that it's looking in /usr/bin:

--8<---cut here---start->8---
mhw@jojen ~$ epiphany

** (epiphany:1016): WARNING **: 18:36:48.495: Registering special URI scheme 
ftp is no longer allowed
bwrap: Can't find source path /usr/bin: No such file or directory
--8<---cut here---end--->8---

I wonder if this only works when Guix is run on top of a more
traditional OS that has /usr/bin.

Is anyone successfully able to use Epiphany on a pure Guix system
(without /usr/bin) with Webkitgtk-2.32.0?  (The Webkitgtk version is
shown in the "About Web" window, which is accessible from the hamburger
menu.

  Mark

bug#47627: syncthing package is vulnerable to CVE-2021-21404

[Leo Famulari]

On Wed, Apr 07, 2021 at 12:40:03AM +0200, Léo Le Bouter via Bug reports for GNU 
Guix wrote:
> CVE-2021-2140406.04.21 22:15
> Syncthing is a continuous file synchronization program. In Syncthing
> before version 1.15.0, the relay server `strelaysrv` can be caused to
> crash and exit by sending a relay message with a negative length field.
> Similarly, Syncthing itself can crash for the same reason if given a
> malformed message from a malicious relay server when attempting to join
> the relay. Relay joins are essentially random (from a subset of low
> latency relays) and Syncthing will by default restart when crashing, at
> which point it's likely to pick another non-malicious relay. This flaw
> is fixed in version 1.15.0.
> 
> We still ship 1.5.0, we crucially need to update that *very* useful
> networked daemon package. With the new go importer maybe that's easier.
> Also work in the go build system needs to happen IIRC.
> 
> Previous discussion about updating syncthing: 
> https://issues.guix.gnu.org/45476

Yeah. Given this report, we could also just build Syncthing with the
bundled source code, which is freely licensed.


signature.asc
Description: PGP signature

bug#47628: webkitgtk-2.32.0 is broken on my system (was Re: bug#47628: Epiphany fails to launch after webkitgtk-2.32.0 update)

[Mark H Weaver]

retitle 47628 webkitgtk-2.32.0 is broken on my system
thanks

Mark H Weaver  writes:

> FYI, since updating to webkitgtk-2.32.0 (commit
> 3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no
> window appears, although GNOME Shell shows an empty outline in overview
> mode, as if there's a window but it has never been painted.
>
> When running 'epiphany' from the command line, I see the followin
> warning from 'bwrap', which indicates that it's looking in /usr/bin:

I see exactly the same behavior with 'eolie': the window never appears,
(except for an outline in GNOME Shell's overview mode), and I see the
same warning:

  "bwrap: Can't find source path /usr/bin: No such file or directory"

In both cases, if I try to close the phantom window from overview mode,
it informs me that the application is not responding, and I have to
force quit to make the phantom window go away.

   Mark

bug#33848: Store references in SBCL-compiled code are "invisible"

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:

> On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Courtès wrote:
>> The GC’s scanner still gets it wrong though.  I wonder whether having
>> the grafting code more capable than the scanner could lead to bad
>> surprises.  WDYT?
>
> I'm going off-topic, but I've wished we had a generic fast string-search
> (and replace?) procedure.

Guile has several functions to help with this, e.g. 'string-contains',
'string-replace', 'string-replace-substring', and of course the regexp
functions.

The grafting code can't use these things because (1) we are not
searching for a single string, but rather for arbitrary nix hashes, and
(2) we can't easily use the regexp functions because there could be NULs
present.

> The go-build-system has a slow "one byte a time" implementation because
> I couldn't figure out how to re-use the code in (guix build grafts):
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/go-build-system.scm?h=v1.2.0#n269

>From a glance, I would think that 'replace-store-references' from
(guix build grafts) is directly applicable here.  Do you remember what
the difficulty was in using it?

Alternatively, since you are only searching for a single string to
replace, I think you could read the entire file into a single string
(e.g. using 'get-string-all' with "ISO-8859-1" encoding) and use
'string-replace-substring'.

What do you think?

  Mark

bug#47225: QEMU warning about performance

[Maxim Cournoyer]

Hi Leo!

Leo Famulari  writes:

> On Tue, Apr 06, 2021 at 05:42:15PM -0400, Maxim Cournoyer wrote:
>> From c720e68229322e5c38c0321b021e8d6430636111 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer 
>> Date: Tue, 6 Apr 2021 17:37:33 -0400
>> Subject: [PATCH] system: vm: Set a larger value for the msize option of the 
>> 9p
>>  file system.
>> 
>> Fixes .
>> 
>> * gnu/system/vm.scm (mapping->file-system): Set the msize option to a value 
>> of
>> 100 MiB (from the default 8 KiB).
>> 
>> Reported-by: Leo Famulari 
>
> Thanks! I'll test and push along with the next kernel update (that's
> when I noticed this warning). Feel free to push sooner if you like.

I hope I'm timely; I've made a revised version of the patch, that should
cover more cases (and actually uses 100 MiB rather than 1 MiB :-)).

Thank you,

From eb600c4ffbc8016709db9471f9dc0be1d60167a7 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Tue, 6 Apr 2021 17:37:33 -0400
Subject: [PATCH] system: vm: Set a larger value for the msize option of the 9p
 file system.

Fixes .

* gnu/system/vm.scm (%default-msize-value): New variable.
(%linux-vm-file-systems): Use it as the value of the msize option.
(mapping->file-system): Likewise.

Reported-by: Leo Famulari 
---
 gnu/system/vm.scm | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 3d0935b3af..1efae7ff06 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -88,6 +88,13 @@
 ;;;
 ;;; Code:
 
+;; By default, the msize value is 8 KiB, which according to QEMU is
+;; insufficient and would degrade performance.  The msize value should roughly
+;; match the bandwidth of the system's IO (see:
+;; https://wiki.qemu.org/Documentation/9psetup#msize).  Use 100 MiB as a
+;; conservative default.
+(define %default-msize-value (* 100 (expt 2 20))) ;100 MiB
+
 (define %linux-vm-file-systems
   ;; File systems mounted for 'derivation-in-linux-vm'.  These are shared with
   ;; the host over 9p.
@@ -103,21 +110,23 @@
   (type "9p")
   (needed-for-boot? #t)
   (flags '(read-only))
-  (options "trans=virtio,cache=loose")
+  (options (format #f "trans=virtio,cache=loose,msize=~a"
+   %default-msize-value))
   (check? #f))
 (file-system
   (mount-point "/xchg")
   (device "xchg")
   (type "9p")
   (needed-for-boot? #t)
-  (options "trans=virtio")
+  (options (format #f "trans=virtio,msize=~a" %default-msize-value))
   (check? #f))
 (file-system
   (mount-point "/tmp")
   (device "tmp")
   (type "9p")
   (needed-for-boot? #t)
-  (options "trans=virtio,cache=loose")
+  (options (format #f "trans=virtio,cache=loose,msize=~a"
+   %default-msize-value))
   (check? #f
 
 (define not-config?
@@ -581,7 +590,8 @@ the operating system."
(type "9p")
(flags (if writable? '() '(read-only)))
(options (string-append "trans=virtio"
-   (if writable? "" ",cache=loose")))
+   (if writable? "" ",cache=loose")
+   ",msize=" (number->string %default-msize-value)))
(check? #f)
(create-mount-point? #t)
 
-- 
2.31.1



signature.asc
Description: PGP signature

bug#47614: [security] Chunked store references in .zo files in Racket 8 #47614

[Philip McGrath]

Ah, I see the thread for https://issues.guix.gnu.org/47614 wasn't cc'ed 
here:



 Forwarded Message 
Subject: Re: Racket 8 and store references (was [security] Chunked store 
references in .zo files in Racket 8 #47614)

Date: Tue, 6 Apr 2021 21:38:57 -0400
From: Philip McGrath 
To: Jack Hill , Mark H Weaver 
CC: guix-de...@gnu.org

Indeed, I expect this is a more precise diagnosis of the same problem. 
My patch in https://issues.guix.gnu.org/47180 solves it by putting the 
store references (search paths for foreign libraries) in a configuration 
data file that isn't compiled, so they don't end up in .zo files in the 
first place.


The .zo format is intentionally undocumented and subject to breaking 
change, including from different compilation options. At a minimum, a 
change to the Racket version number signals a breaking change to 
compiled code (e.g. Git is now at 8.0.0.13, so 13 breaking changes since 
the release). Internally, I don't know all the details, but the normal 
8.0 .zo format has a Racket layer around the Chez Scheme object format, 
which seems to be very complex: it looks like it supports 
user-configurable compression at the granularity of the individual 
object within an object file. So it seems much better to avoid rewriting 
.zo files altogether.


-Philip

On 4/6/21 9:20 PM, Jack Hill wrote:

On Tue, 6 Apr 2021, Mark H Weaver wrote:


Anyway, I doubt that imposing such a limitation would adequately solve
the problem here of chunked references in Racket 8, because I suspect
that Racket 8 could split store references at arbitrary points in the
string.  I doubt that we can safely assume that the hash component of
store references will be stored contiguously in *.zo files.


Mark and everyone,

I wanted to spin off a subthread on guix-devel, to make you aware of 
another problem that we've run into with reference in .zo getting 
mangled: https://issues.guix.gnu.org/47180


Best,
Jack