bug#47576: [security] ibus-daemon launches ungrafted subprocesses

[Ludovic Courtès]

Hi,

Mark H Weaver  skribis:

> I found them:
>
>   ~/.cache/ibus/bus/registry
>   /var/lib/gdm/.cache/ibus/bus/registry
>
> On my system, those files include absolute pathnames to programs in
> /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22, which I
> compiled last December.

Looks like .

The problem seems to generally affect GLib/GNOME-ish caches.

>From a quick look at ibusregistry.c & co, I think the values that end up
in the cache are taken from these XML files:

--8<---cut here---start->8---
$ grep /gnu/store $(find $(guix build ibus) -name \*.xml)
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/gtkpanel.xml:
  
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-ui-gtk3
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/dconf.xml:
 
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-dconf
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/simple.xml:

/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-engine-simple
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/gtkextension.xml:
  
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-extension-gtk3
--8<---cut here---end--->8---

It’s the ‘components’ field of _IBusRegistryPrivate:

--8<---cut here---start->8---
struct _IBusRegistryPrivate {
/* a list of IBusObservedPath objects. */
GList *observed_paths;

/* a list of IBusComponent objects that are created from component XML
 * files (or from the cache of them). */
GList *components;

gboolean changed;

/* a mapping from GFile to GFileMonitor. */
GHashTable *monitor_table;

guint monitor_timeout_id;
};
--8<---cut here---end--->8---

The attached patch does the following:

  1. change the above  file names in XML files to relative file
 names;

  2. change ibuscomponent.c to automatically prepend $libexecdir to
  items that are relative file names.

That way, XML files and thus caches should only contain relative file
names for ibus’ own executables.

The attached patch builds with:

  guix build ibus --with-patch=ibus=/tmp/ibus.patch

… but I don’t know if it actually works.  Testing welcome.  :-)

Unfortunately this strategy doesn’t help with IBus extensions:

--8<---cut here---start->8---
$ grep exec $(find $(guix build ibus-anthy) -name \*.xml)
/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/share/ibus/component/anthy.xml:

/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/libexec/ibus-engine-anthy
 --ibus
/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/share/ibus/component/anthy.xml:

--8<---cut here---end--->8---

Thoughts?

Ludo’.

diff --git a/conf/dconf/dconf.xml.in b/conf/dconf/dconf.xml.in
index 4205cb0..538f500 100644
--- a/conf/dconf/dconf.xml.in
+++ b/conf/dconf/dconf.xml.in
@@ -3,7 +3,7 @@
 
 	org.freedesktop.IBus.Config
 	Dconf Config Component
-	@libexecdir@/ibus-dconf
+	ibus-dconf
 	@VERSION@
 	Daiki Ueno 
 	GPL
diff --git a/conf/memconf/memconf.xml.in b/conf/memconf/memconf.xml.in
index d6ea690..9f51bcc 100644
--- a/conf/memconf/memconf.xml.in
+++ b/conf/memconf/memconf.xml.in
@@ -2,7 +2,7 @@
 
 	org.freedesktop.IBus.Config
 	On-memory Config Component
-	@libexecdir@/ibus-memconf
+	ibus-memconf
 	@VERSION@
 	Peng Huang , modified by the Chromium OS Authors
 	GPL
diff --git a/engine/simple.xml.in b/engine/simple.xml.in
index fc1541e..47cbea1 100644
--- a/engine/simple.xml.in
+++ b/engine/simple.xml.in
@@ -2,7 +2,7 @@
 
 	org.freedesktop.IBus.Simple
 	A table based simple engine
-	@libexecdir@/ibus-engine-simple
+	ibus-engine-simple
 	@VERSION@
 	Peng Huang 
 	GPL
diff --git a/src/Makefile.am b/src/Makefile.am
index a8e3d07..2c461ee 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -49,6 +49,7 @@ AM_CPPFLAGS =   \
 @GLIB2_CFLAGS@  \
 @GOBJECT2_CFLAGS@   \
 @GIO2_CFLAGS@   \
+-DLIBEXECDIR=\"$(libexecdir)\"			\
 -DIBUS_CACHE_DIR=\""$(localstatedir)/cache/ibus"\"  \
 -DIBUS_DATA_DIR=\"$(pkgdatadir)\"   \
 -DIBUS_DISABLE_DEPRECATION_WARNINGS \
diff --git a/src/Makefile.in b/src/Makefile.in
index 2a9c2ab..c3dfd87 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -613,6 +613,7 @@ CLEANFILES = $(am__append_2) $(BUILT_SOURCES) stamp-ibusmarshalers.h \
 # C preprocessor flags
 AM_CPPFLAGS = -DG_LOG_DOMAIN=\"IBUS\" @GLIB2_CFLAGS@ @GOBJECT2_CFLAGS@ \
 	@GIO2_CFLAGS@ \
+	-DLIBEXECDIR=\"$(

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley via Bug reports for GNU Guix]

The Exec paths in these files already refer to absolute paths, infact, 
/gnu/store paths
Thus the regex:

("^Exec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)

with binary = empty string and rest = everything after Exec=

Why? The second subexpression [^/[:blank:]\r\n]* is bound to binary, but it 
means anything
that is a series of anything that is not /, space, or newline. absolute paths 
start with /, so it matches nothing (empty string), and continues to call 
(which "").


I notice this phase hasn't been edited in 5 years and has other issues, for 
example:

1. patch-dot-desktop-files only searches the output of the package for paths, 
not the inputs. This means for example xfce4-settings fails to patch references 
to exo-open in desktop files.

The code should be remade to be more /correct/, and handle all unexpected 
inputs. In this case the phase is accidentally doing the right thing by failing 
in a harmless way and correctly not patching the files, but emitting a warning.

bug#47672: owncloud-client : "Could not read system exclude file"

[Fulbert]

Hello !

After setting up an account to a davs server, the synchronisation
fails with messages :

* On the GUI : "Could not read system exclude file"

* In log file :
20210409_1235_owncloud.log.0.gz:04-09 12:35:55:294 [ info sync.configfile ]:
Adding system ignore list to csync: 
"/home/fulbert/etc/ownCloud/sync-exclude.lst"
20210409_1235_owncloud.log.0.gz:04-09 12:35:55:294 [ info sync.configfile ]:
Adding user defined ignore list to csync: 
"/home/fulbert/.config/ownCloud/sync-exclude.lst"
20210409_1235_owncloud.log.0.gz:04-09 12:35:55:295 [ warning gui.folder ]: 
Could not read system exclude file

After a little web search, I have not found a way to change the
path to the *system* `sync-exclude.lst` file, whether through GUI,
configuration file or environement variable.

brutal workaround :
$ mkdir $HOME/etc/ownCloud
$ ln -s $HOME/.guix-profile/etc/ownCloud/sync-exclude.lst $HOME/etc/ownCloud

Thanks and best regards.

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Pierre Neidhardt]

Thanks for the investigation.  Would you like to send a patch?


signature.asc
Description: PGP signature

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley via Bug reports for GNU Guix]

> On 04/09/2021 1:23 PM Pierre Neidhardt  wrote:
> 
>  
> Thanks for the investigation.  Would you like to send a patch?

I'm not sure what the right way to fix it is. I may have come up with a 
brilliant idea. Untested patch attached.From 64c200f3630de13ec3487cb5c756b47b133c6ecf Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Fri, 9 Apr 2021 21:43:54 +1000
Subject: [PATCH] build: gnu-build-system: Improve patch-dot-desktop-files.

* guix/build/gnu-build-system.scm (patch-dot-desktop-files):
When patching .desktop files, Exec= values beginning with '/', (or
spaces or newline characters) will result in the 'binary' symbol
matching an empty string. Changing *, meaning 0 or more, to +, meaning 1
or more ensures it will match a binary of atleast 1 length, or nothing.
---
 guix/build/gnu-build-system.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index 2e7dff2034..99636c442a 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -725,9 +725,9 @@ which cannot be found~%"
  ;; UTF-8-encoded.
  (with-fluids ((%default-port-encoding "UTF-8"))
(substitute* files
- (("^Exec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
+ (("^Exec=([^/[:blank:]\r\n]+)(.*)$" _ binary rest)
   (string-append "Exec=" (which binary) rest))
- (("^TryExec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
+ (("^TryExec=([^/[:blank:]\r\n]+)(.*)$" _ binary rest)
   (string-append "TryExec="
  (which binary) rest)
 outputs)
-- 
2.31.1

bug#47667: rust-rav1e-0.4 fails to build

[Nicolas Goaziou]

Hello,

Leo Famulari  writes:

> I got it building with 29a6c361492b18bcb0f6d2517d010a1b48441521, adding
> some inputs that the rav1e package also has.
>
> Maybe we should merge these packages?

Unless I'm missing something rust-rav1e-0.4 is not supposed to be built,
per its `skip-build' keyword. I'm surprised it chokes this way.

"rav1e" packages, i.e., without the "rust-" prefix, are the ones
actually being built. That's not the same intent.

Regards,
-- 
Nicolas Goaziou

bug#45187: git download defaults to origin/master

[Ludovic Courtès]

Hi!

Kyle Meyer  skribis:

> Subject: [PATCH] git: Update cached checkout to the remote HEAD by default.
>
> Fixes .
> Reported by Ricardo Wurmus .
>
> update-cached-checkout hard codes "master" as the default branch, leading to a
> failure when the clone doesn't have a "master" branch.  Instead use the remote
> HEAD symref as an indicator of what the primary branch is.
>
> * guix/git.scm (resolve-reference): Support resolving symrefs.
> (update-cached-checkout, latest-repository-commit): Default to the remote HEAD
> symref.
> (): Add symref field that defaults to "HEAD", and change branch
> field's default to #f.
> (git-checkout-compiler): Handle symref field of .

[...]

>git-checkout make-git-checkout
>git-checkout?
>(url git-checkout-url)
> -  (branch  git-checkout-branch (default "master"))
> +  (branch  git-checkout-branch (default #f))
> +  (symref  git-checkout-symref (default "HEAD"))

I know it’s established Git jargon, but “symref” looks obscure to me.
I find it OK for ‘update-cached-checkout’, because it’s an “internal”
procedure for die-hard hackers, but a bit ugly here.

Another option would be to not add this ‘symref’ field and instead, when
‘branch’ and ‘commit’ are both #f, translate that to '(symref . "HEAD").

WDYT?

The rest of the patch LGTM, thanks!

Ludo’.

bug#32515: GNOME thumbnailing code execution vulnerabilities.

[Maxime Devos]

Leo Famulari (26 Feb 2019) wrote:
> Since this bug was filed, Ghostscript has received more scrutiny and
> serious bugs continue to be found.

I assume you meant ‘fixed’.

> [...]
> Barring that, we should keep our package up to date

ghostscript can be updated to 9.54 
(https://ghostscript.com/download/gsdnld.html).
This will require grafts due to many depending packages.
However, looking at
https://bugs.ghostscript.com/buglist.cgi?order=Bug%20Number&product=Ghostscript&query_format=advanced&resolution=---&version=9.52&version=9.53.0&version=9.53.1&version=9.53.2&version=9.53.3&version=9.54.0
it seems there are no known security vulnerabilities.

evince can be updated from 3.36.5 to 40.0 according to "guix refresh",
that would be done in https://issues.guix.gnu.org/47643  think.

> and try to make sure
> the GNOME thumbnailer and other "hidden" users of Ghostscript are run in
> containers.

The thumbnailer is run in a container, using bubblewrap and seccomp:

$ guix graph --type=references gnome-desktop
> [snip]
> "/gnu/store/82lh0zkg0jc64j7k9liz75yrzn3aqzp7-gnome-desktop-3.34.2" -> 
> "/gnu/store/jsw78nn91z34z2cm227zwjhpybx2p2lw-bubblewrap-0.4.1" [color = 
> darkseagreen];
> "/gnu/store/82lh0zkg0jc64j7k9liz75yrzn3aqzp7-gnome-desktop-3.34.2" -> 
> "/gnu/store/w668dl13dac6gpxvyhic21dnifrrijp6-libseccomp-2.5.1" [color = 
> darkseagreen];
> [snip]

$ EDITOR=less guix edit gnome-desktop
> [snip]
> ("bubblewrap" ,bubblewrap)
> [snip]

$ cat ./libgnome-desktop/gnome-desktop-thumbnail-script.c:
> [snip]
> [an add_bwrap function with bind mounts and --unshare-all]
> [a setup_seccomp function]
> [snip]

Closing.

Greetings,
Maxime.


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

bug#47674: dnsmasq is vulnerable to CVE-2021-3448

[Nicolò Balzarotti]

CVE-2021-3448

A flaw was found in dnsmasq in versions before 2.85. When configured to
use a specific server for a given network interface, dnsmasq uses a
fixed port while forwarding queries. An attacker on the network, able to
find the outgoing port used by dnsmasq, only needs to guess the random
transmission ID to forge a reply and get it accepted by dnsmasq. This
flaw makes a DNS Cache Poisoning attack much easier. The highest threat
from this vulnerability is to data integrity.

guix ships dnsmasq@2.84. guix refresh shows version 2.85 is available,
and there are 43 dependent packages so this can go directly to master.

All dependent packages (refresh -l) build fine except for
python2-libvirt@7.2.0, which is failing also on master
(libvirt-python requires Python >= 3.5 to build).  Since it's a python2
package and no other packages depends on it, can we just drop it?

Thanks, Nicolò

>From a0932442c6c72d1e1a2a0f400f8afa487251189d Mon Sep 17 00:00:00 2001
From: nixo 
Date: Fri, 9 Apr 2021 16:19:03 +0200
Subject: [PATCH] gnu: dnsmasq: Update to 2.85.

* gnu/packages/dns.scm (dnsmasq): Update to 2.85.
---
 gnu/packages/dns.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/dns.scm b/gnu/packages/dns.scm
index c940657ce9..3cf88febae 100644
--- a/gnu/packages/dns.scm
+++ b/gnu/packages/dns.scm
@@ -278,7 +278,7 @@ prompt the user with the option to go with insecure DNS only.")
 (define-public dnsmasq
   (package
 (name "dnsmasq")
-(version "2.84")
+(version "2.85")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -286,7 +286,7 @@ prompt the user with the option to go with insecure DNS only.")
 version ".tar.xz"))
   (sha256
(base32
-"0305a0c3snwqcv77sipyynr55xip1fp2843yn04pc4vk9g39acb0"
+"1yhjwgz8g5qrqvxh6bbmg3443zi8qqjks3q872wyb1zn7n0d765d"
 (build-system gnu-build-system)
 (native-inputs
  `(("pkg-config" ,pkg-config)))
-- 
2.31.1

bug#30790: Broken Qt 5 in my main profile - Qt DBus ?

[Maxim Cournoyer]

Hi Danny,

Danny Milosavljevic  writes:

> Hi,
>
> seems I broke Qt 5 in my main profile by updating some packages.
>
> I've got this situation:
>
> /gnu/store/gdcnj399zhkpa5kf2mnzgg9lfb3nnd0h-lyx-2.2.3$ gdb 
> share/lyx/bin/lyx2.2
> (gdb) r
> Cannot mix incompatible Qt library (version 0x50903) with this library 
> (version 0x50904)
> Aborted
> (gdb) bt
> #0 0x750a41e4 in raise () from
> /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libc.so.6
> #1 0x750a55e5 in abort () from
> /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libc.so.6
> #2 0x761c5f0e in QMessageLogger::fatal(char const*, ...) const
> () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #3 0x763c5301 in QObjectPrivate::QObjectPrivate(int) () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #4 0x7fffedaae100 in ?? () from
> /gnu/store/4if0il1fssgh3zna4b3x9lwbgw49z01m-qtbase-5.9.3/lib/qt5/plugins/platforms/../../../libQt5DBus.so.5
> #5 0x7fffedaaeed4 in
> QDBusAbstractInterface::QDBusAbstractInterface(QString const&, QString
> const&, char const*, QDBusConnection const&, QObject*) () from
> /gnu/store/4if0il1fssgh3zna4b3x9lwbgw49z01m-qtbase-5.9.3/lib/qt5/plugins/platforms/../../../libQt5DBus.so.5
> #6 0x7fffeda98759 in
> QDBusConnectionInterface::QDBusConnectionInterface(QDBusConnection
> const&, QObject*) () from
> /gnu/store/4if0il1fssgh3zna4b3x9lwbgw49z01m-qtbase-5.9.3/lib/qt5/plugins/platforms/../../../libQt5DBus.so.5
> #7 0x7fffeda94d18 in ?? () from
> /gnu/store/4if0il1fssgh3zna4b3x9lwbgw49z01m-qtbase-5.9.3/lib/qt5/plugins/platforms/../../../libQt5DBus.so.5
> #8 0x7fffeda9552d in ?? () from
> /gnu/store/4if0il1fssgh3zna4b3x9lwbgw49z01m-qtbase-5.9.3/lib/qt5/plugins/platforms/../../../libQt5DBus.so.5
> #9 0x763c88f1 in QObject::event(QEvent*) () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #10 0x7639dc63 in QCoreApplication::notifyInternal2(QObject*,
> QEvent*) () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #11 0x763a030b in
> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
> () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #12 0x763f0583 in ?? () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #13 0x717cd5c7 in g_main_context_dispatch () from
> /gnu/store/i1x64fz6m3i1l61vywn5bgdamw0h71c0-glib-2.54.2/lib/libglib-2.0.so.0
> #14 0x717cd808 in g_main_context_iterate.isra () from
> /gnu/store/i1x64fz6m3i1l61vywn5bgdamw0h71c0-glib-2.54.2/lib/libglib-2.0.so.0
> #15 0x717cd8ac in g_main_context_iteration () from
> /gnu/store/i1x64fz6m3i1l61vywn5bgdamw0h71c0-glib-2.54.2/lib/libglib-2.0.so.0
> #16 0x763efbcf in
> QEventDispatcherGlib::processEvents(QFlags)
> () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #17 0x7639c25a in
> QEventLoop::exec(QFlags) () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #18 0x761d819c in QThread::exec() () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #19 0x7fffeda939d5 in ?? () from
> /gnu/store/4if0il1fssgh3zna4b3x9lwbgw49z01m-qtbase-5.9.3/lib/qt5/plugins/platforms/../../../libQt5DBus.so.5
> #20 0x761dcd6a in ?? () from
> /gnu/store/rr0225gz6qb1j9xwc5iinf1143dg6cw6-qtbase-5.9.4/lib/libQt5Core.so.5
> #21 0x74e594d5 in start_thread () from
> /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
> #22 0x751602cf in clone () from
> /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libc.so.6
>
> So it's apparently Qt DBus related since the version of Qt DBus is 5.9.3 but 
> the other Qt stuff is 5.9.4.
>
> If I unset QT_PLUGIN_PATH, it works.
>
> QT_PLUGIN_PATH was:
>
> $HOME/.guix-profile/lib/qt5/plugins

I believe the plugins are dynamically loaded, so if you were to have a
mixture of plugins built against various versions of Qt, problems could
occur.

I don't see a good solution for that, short of upgrading your whole
profile.

Unless you have ideas to research to improve this situation, I suggest
we close this issue.

What do you think?

Maxim

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

[Ludovic Courtès]

Ludovic Courtès  skribis:

>>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(-)

Pushed as 2d73086262e1fb33cd0f0f16f74a495fe06b38aa with the
corresponding ‘guix’ package update in
ec8d09ee672e0d357bb5bb597464c8b168f14bfb.

Ludo’.

bug#47675: quiterss segfaults

[Maxime Devos]

Hi Guix,

$ guix --version
> guix (GNU Guix) 29a6c361492b18bcb0f6d2517d010a1b48441521
> [...]

$ guix environment --ad-hoc --pure coreutils which gdb quiterss -E "XAUTHORITY" 
-E "DISPLAY" -- quiterss
> # (No output)

$ guix environment --ad-hoc --pure coreutils which gdb quiterss -E "XAUTHORITY" 
-E "DISPLAY" --
[env]$ quiterss
> Segmentation fault
$ cat `which quiterss`
> [export things, and an exec line]
$ [the export
lines]
$ gdb .quiterss-real
(gdb) start
(gdb) continue

(visual output)  Loading: 30%  0.19.4  QuiteRSS, free news reader (progress bar)
> Continuing.
> [New Thread 0x7fffeefc2700 (LWP 25287)]
> [New Thread 0x7fffe4d6c700 (LWP 25288)]
> [New Thread 0x7fffd700 (LWP 25289)]
> [New Thread 0x7fffdf7fe700 (LWP 25290)]
> [New Thread 0x7fffdeffd700 (LWP 25291)]
>
> Thread 1 ".quiterss-real" received signal SIGSEGV, Segmentation fault.
> 0x77b4cdab in QHeaderViewPrivate::createSectionItems(int, int, int, 
> QHeaderView::ResizeMode) ()
>   from 
> /gnu/store/gdg69dfp58q5lbfd9armvazh8bmyf4j0-qtbase-5.15.2/lib/libQt5Widgets.so.5

(gdb) bt
> #0  0x77b4cdab in QHeaderViewPrivate::createSectionItems(int, int, 
> int, QHeaderView::ResizeMode) () from 
> /gnu/store/gdg69dfp58q5lbfd9armvazh8bmyf4j0-qtbase-5.15.2/lib/libQt5Widgets.so.5
> #1  0x77b4d9f2 in QHeaderView::setSectionResizeMode(int, 
> QHeaderView::ResizeMode) ()
>from 
> /gnu/store/gdg69dfp58q5lbfd9armvazh8bmyf4j0-qtbase-5.15.2/lib/libQt5Widgets.so.5
> #2  0x005437bd in ?? ()
> #3  0x00544ac3 in ?? ()
> #4  0x004f9ee6 in ?? ()
> #5  0x00449a70 in main ()

Again, this time with --with-debug-info=quiterss:

(gdb) bt
> [grrr! no improvement]

Greetings,
Maxime


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

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Pierre Neidhardt]

So if the path is already an absolute store path, then I suppose that
the whole phase is superfluous, isn't it?

Couldn't we just delete it?

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


signature.asc
Description: PGP signature

bug#47667: rust-rav1e-0.4 fails to build

[Leo Famulari]

On Fri, Apr 09, 2021 at 03:18:33PM +0200, Nicolas Goaziou wrote:
> Unless I'm missing something rust-rav1e-0.4 is not supposed to be built,
> per its `skip-build' keyword. I'm surprised it chokes this way.

Huh, I don't know... it started to fail after changes to the
cargo-build-system.

bug#32515: GNOME thumbnailing code execution vulnerabilities.

[Leo Famulari]

On Fri, Apr 09, 2021 at 03:51:21PM +0200, Maxime Devos wrote:
> Leo Famulari (26 Feb 2019) wrote:
> > Since this bug was filed, Ghostscript has received more scrutiny and
> > serious bugs continue to be found.
> 
> I assume you meant ‘fixed’.

I did not mean 'fixed'. As far as I know, no work was done in Guix about
this bug.

'filed' is definitely the correct interpretation; security researchers
ignored postscript / Ghostcript for a very long time, but it became a
popular area of research a few years ago.

Basically, Ghostscript is a decades-old C codebase implementing an even
older language specification. Caveat emptor.

Unlike some other similar codebases, like OpenSSL, the situation
regarding security researchers and vulnerability disclosure has not
really improved, as far as I can tell :/


> The thumbnailer is run in a container, using bubblewrap and seccomp:
> 
> $ guix graph --type=references gnome-desktop
> > [snip]
> > "/gnu/store/82lh0zkg0jc64j7k9liz75yrzn3aqzp7-gnome-desktop-3.34.2" -> 
> > "/gnu/store/jsw78nn91z34z2cm227zwjhpybx2p2lw-bubblewrap-0.4.1" [color = 
> > darkseagreen];
> > "/gnu/store/82lh0zkg0jc64j7k9liz75yrzn3aqzp7-gnome-desktop-3.34.2" -> 
> > "/gnu/store/w668dl13dac6gpxvyhic21dnifrrijp6-libseccomp-2.5.1" [color = 
> > darkseagreen];
> > [snip]
> 
> $ EDITOR=less guix edit gnome-desktop
> > [snip]
> > ("bubblewrap" ,bubblewrap)
> > [snip]
> 
> $ cat ./libgnome-desktop/gnome-desktop-thumbnail-script.c:
> > [snip]
> > [an add_bwrap function with bind mounts and --unshare-all]
> > [a setup_seccomp function]
> > [snip]
> 
> Closing.

Great, looks like upstream took care of it for us. There will probably
be more bugs in this area, but that's expected.


signature.asc
Description: PGP signature

bug#47674: dnsmasq is vulnerable to CVE-2021-3448

[Leo Famulari]

On Fri, Apr 09, 2021 at 05:10:43PM +0200, Nicolò Balzarotti wrote:
> CVE-2021-3448
> 
> A flaw was found in dnsmasq in versions before 2.85. When configured to
> use a specific server for a given network interface, dnsmasq uses a
> fixed port while forwarding queries. An attacker on the network, able to
> find the outgoing port used by dnsmasq, only needs to guess the random
> transmission ID to forge a reply and get it accepted by dnsmasq. This
> flaw makes a DNS Cache Poisoning attack much easier. The highest threat
> from this vulnerability is to data integrity.
> 
> guix ships dnsmasq@2.84. guix refresh shows version 2.85 is available,
> and there are 43 dependent packages so this can go directly to master.
> 
> All dependent packages (refresh -l) build fine except for
> python2-libvirt@7.2.0, which is failing also on master
> (libvirt-python requires Python >= 3.5 to build).  Since it's a python2
> package and no other packages depends on it, can we just drop it?

Yes, sounds good.


signature.asc
Description: PGP signature

bug#47674: dnsmasq is vulnerable to CVE-2021-3448

[Leo Famulari]

On Fri, Apr 09, 2021 at 05:10:43PM +0200, Nicolò Balzarotti wrote:
> From a0932442c6c72d1e1a2a0f400f8afa487251189d Mon Sep 17 00:00:00 2001
> From: nixo 
> Date: Fri, 9 Apr 2021 16:19:03 +0200
> Subject: [PATCH] gnu: dnsmasq: Update to 2.85.
> 
> * gnu/packages/dns.scm (dnsmasq): Update to 2.85.

Looks like this change was already done with commit
c8d809f9a49c2b4ec5500c2685e96168dcd9afa9

bug#47674: dnsmasq is vulnerable to CVE-2021-3448

[Leo Famulari]

On Fri, Apr 09, 2021 at 05:10:43PM +0200, Nicolò Balzarotti wrote:
> All dependent packages (refresh -l) build fine except for
> python2-libvirt@7.2.0, which is failing also on master
> (libvirt-python requires Python >= 3.5 to build).  Since it's a python2
> package and no other packages depends on it, can we just drop it?

I notice that python2-libvirt builds okay on staging:

https://ci.guix.gnu.org/search?query=python2-libvirt&border-high-id=134835

bug#47674: dnsmasq is vulnerable to CVE-2021-3448

[Nicolò Balzarotti]

Leo Famulari  writes:

> On Fri, Apr 09, 2021 at 05:10:43PM +0200, Nicolò Balzarotti wrote:
>> All dependent packages (refresh -l) build fine except for
>> python2-libvirt@7.2.0, which is failing also on master
>> (libvirt-python requires Python >= 3.5 to build).  Since it's a python2
>> package and no other packages depends on it, can we just drop it?
>
> I notice that python2-libvirt builds okay on staging:
>
> https://ci.guix.gnu.org/search?query=python2-libvirt&border-high-id=134835

Staging has an older version (5.8 vs 7.2, which has been released in
november 2019 [fn:1] though), and it got updated a few days ago
(28cc447fc5bd0a219ad54836a343826cc34d9bd7) if I'm not wrong, so it should
fail on staging too.  Am I wrong?


[fn:1] https://pypi.org/project/libvirt-python/#history

bug#47674: dnsmasq is vulnerable to CVE-2021-3448

[Leo Famulari]

On Fri, Apr 09, 2021 at 09:47:13PM +0200, Nicolò Balzarotti wrote:
> Staging has an older version (5.8 vs 7.2, which has been released in
> november 2019 [fn:1] though), and it got updated a few days ago
> (28cc447fc5bd0a219ad54836a343826cc34d9bd7) if I'm not wrong, so it should
> fail on staging too.  Am I wrong?

Ah, could be. The new staging builds haven't been performed yet.

bug#47660: Add link to the ticket when someone reply

[bo0od]

This work or i search for it also work, But we are talking making things 
much easier and its possible through providing the link directly to the 
ticket in bottom, I believe this practice followed by all major 
ticketing systems,platforms,projects.. So i dont understand whats the 
big deal having it here as well.




Leo Famulari:

On Thu, Apr 08, 2021 at 05:38:59PM +, bo0od wrote:

Hi There,

When someone reply to my ticket and receive the message through email there
is no URL included to the ticket, Which mean if i forgot what i have wrote
before then i need to go and see what was the conversation by using ticket
title in gnu bug which not nice.

Please add URL of the ticket always to the bottom.


If you find yourself forgetting, you can use the bug number.

The bug number is in the email address and the subject line, and you can
use it like this:

https://issues.guix.gnu.org/issue/47660

Does that help?

bug#47633: Provide direct download to .iso

[bo0od]

> The reason is to save bandwidth.

For the user or for the website? If its for the website i dont see 200MB 
(difference between .iso and .xz) is making a big deal different, And if 
the complain real about that in Megabytes then there shouldnt be a 
direct download to the image not .xz nor as .iso it should be only used 
with torrents (or any similar protocol).


ArchLinux doing that:

https://archlinux.org/download/

But providing direct download to the image over https i dont see its 
justified to say it saves bandwidth by compressing it.(unmentioned/very 
minimal saving)


To save bandwidth as well by providing https is by using mirrors. (i 
think there are too many out there)


But if its for the user, Then i dont see any complains from users over 
downloading multiple GBs of NixOS or debian or qubes or...etc


> 1) Host the uncompressed ISO yourself and send that link to your host
> provider

So the alternative solution is harder than fixing the original problem?

When i report an issue that doesnt mean i dont know how to fix it or i 
cant find alternative solutions, Its not about me but its about the user 
specially new users, so i dont know how new user who paid 5 dollar for 
outside host provider to test Guix or using it, to go and host .iso 
image for guix.


You know whats the alternative easier solution for that user: he go and 
install NixOS or X OS and hes happy with that because it saves time and 
money and effort.


> 2) Ask the host provider to download and uncompress the ISO on their
> own. They should be able to do this because they will have to store the
> ISO file on their servers anyways.

Thats really too much to ask because there are more than one form of 
compression and to do that for 1 or 2 users who want to use this x 
distro which doesnt use the traditional way and not from the famous 
distros (like debian or fedora) i can assure this is not gonna happen 
(at least anytime soon).





Leo Famulari:

On Wed, Apr 07, 2021 at 05:31:57AM +, bo0od wrote:

I see that guix compress its image here:

https://guix.gnu.org/en/download/

Which im not sure why (I dont see any known project doing that),


The reason is to save bandwidth.


But regardless to the reason behind it this is actually give some
problems to users who want to use Guix on outside server, Many host
providers nowadays they give the opportunity to install whatever the
user want from distros according to his wish from outside source but
one thing needed for that is the URL to the .iso , And the host gonna
download/run/import the .iso for the user.


I have two suggestions:

1) Host the uncompressed ISO yourself and send that link to your host
provider

2) Ask the host provider to download and uncompress the ISO on their
own. They should be able to do this because they will have to store the
ISO file on their servers anyways.

bug#47681: Reloading udev rules requires a system restart

[Maxim Cournoyer]

Hello Guix!

Using Guix System, after adding a new rule to the configuration of their
udev-service-type service, the only ways to get the new rule into effect
are to either:

1. restart udev

(which is almost the same as a reboot, bringing down your graphical session)

2. restart the operating system

Both of which are sub-optimal.

This is caused by the configuration file/rules being made known to udev
via environment variables:

$ sudo cat /proc/$(pgrep udev)/environ | xargs -0 -n1 echo
UDEV_CONFIG_FILE=/gnu/store/7yfpf8acjy884xbwaq5kn9z21irchfaj-udev.conf
EUDEV_RULES_DIRECTORY=/gnu/store/yv58b7rg7dm3191cj6sma896550wgy4v-udev-rules/lib/udev/rules.d
LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
PATH=/run/current-system/profile/bin

For convenience, we should probably have the udev-service-type create a
union of what it needs under /etc/udev/ as on other distributions.  udev
could then rely on a fixed location to look things and use its inotify
based mechanism to detect changes and reload automatically when needed.

This could probably fix things such as 'udevadm test' only reading rule
files from under
/gnu/store/svplp9wl0g2ahlv5rf6bhmq3xvp4zzh3-eudev-3.2.9/lib/udev/rules.d,
for example.

Thank you,

Maxim

bug#47634: Accompany .asc and .DIGESTS keys for the ISO

[bo0od]

> Which implies that the signatures are sufficient, right?

Well this is simple question but the answer is sorta deeper, So i will 
answer with yes and no:


yes signatures are sufficient but signatures with PGP has problems, In 
the suggestion above i didnt suggest to diverse the signing methods 
(like for example using signify alongside with gpg) but just adding 
extra steps better than one (more convenience to say that everything is 
going smoothly).


To understand what im talking about i suggest to read:

Why PGP on expiration time:

https://www.whonix.org/wiki/OpenPGP#Issues_with_PGP

Discussion which might consider deprecate the usage of PGP by debian:

https://wiki.debian.org/Teams/Apt/Spec/AptSign

Whonix already using signify alongside with PGP:

https://www.whonix.org/wiki/Signify

Also there are challenges to the concept itself:

https://www.whonix.org/wiki/Verifying_Software_Signatures#Conceptual_Challenges_in_Digital_Signatures_Verification



So I hope by complete reading that you will come to the conclusion that 
either provide as much as possible from extra verification (like 
.asc,DIGESTS,SHA512...etc) or provide alternative verification along 
side with the traditional one like using signify or using something like 
signify and thats it. (i think providing both methods like pgp/signify 
is the best way which suits everybody)








On 9 April 2021 3:34:20 am AEST, bo0od  wrote:

This is nicely written by Qubes documentation:

https://www.qubes-os.org/security/verifying-signatures/


 From that page:


If you’ve already verified the signatures on the ISO directly, then verifying 
digests is not necessary.


Which implies that the signatures are sufficient, right?

What is the benefit to providing the key (.asc) and hashes (.DIGESTS)? The page 
you linked provides rationale for providing and checking digital signatures, 
but we already provide them.

Carlo

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Brendan Tildesley via Bug reports for GNU Guix]

> On 04/09/2021 7:39 PM Pierre Neidhardt  wrote:
> 
>  
> So if the path is already an absolute store path, then I suppose that
> the whole phase is superfluous, isn't it?
> 
> Couldn't we just delete it?

Do you mean delete the phase entirely or just from Racket? It's not always the 
case that they are absolute paths. Racket probably just has some code to 
generate them automatically.

bug#47632: Extracting guix.iso.xz with Xarchiver will give damaged .iso

[bo0od]

Feel free to close this issue, I have tested this scenario again i cant 
reproduce.


Leo Famulari:

On Wed, Apr 07, 2021 at 05:27:49AM +, bo0od wrote:

I have just tested to extract guix.iso.xz using Xarchiver and tried to
install guix.iso on a vbox, The image wont be readable/identified for
installation.


Thanks for the report.

I installed Xarchiver and used it to extract the iso.xz to /tmp.

Then I did this:

--
$ file guix-system-install-1.2.0.x86_64-linux.iso
guix-system-install-1.2.0.x86_64-linux.iso: DOS/MBR boot sector; GRand Unified 
Bootloader, stage1 version 0x79, boot drive 0xbb, stage2 address 0x8e70, 1st 
sector stage2 0xb8db31c3, stage2 segment 0x201
--

So, I think it worked?

I found Xarchiver somewhat complicated...

bug#45187: git download defaults to origin/master

[Kyle Meyer]

Ludovic Courtès writes:

> Kyle Meyer  skribis:
[...]
>>git-checkout make-git-checkout
>>git-checkout?
>>(url git-checkout-url)
>> -  (branch  git-checkout-branch (default "master"))
>> +  (branch  git-checkout-branch (default #f))
>> +  (symref  git-checkout-symref (default "HEAD"))
>
> I know it’s established Git jargon, but “symref” looks obscure to me.
> I find it OK for ‘update-cached-checkout’, because it’s an “internal”
> procedure for die-hard hackers, but a bit ugly here.

Agreed.  As mentioned upthread, I don't like it either.

> Another option would be to not add this ‘symref’ field and instead, when
> ‘branch’ and ‘commit’ are both #f, translate that to '(symref . "HEAD").
>
> WDYT?

Thanks for the suggestion.  Dropping the field and translating
downstream sounds good to me.

Working through the patch update, I ended up moving things even more
internally, making update-cached-checkout translate the empty list into
(symref . "refs/remotes/origin/HEAD") for resolve-reference.  I don't
think there will be a use for symrefs other than HEAD, so it seemed
reasonable to add the special case (or rather shift the special case all
the way down into update-cached-checkout).  Let me know if you'd rather
use a (symref . "HEAD") default for update-cached-checkout.

> The rest of the patch LGTM, thanks!

Thanks for the review.

-- >8 --
Subject: [PATCH v2] git: Update cached checkout to the remote HEAD by default.

Fixes .
Reported by Ricardo Wurmus .

update-cached-checkout hard codes "master" as the default branch, leading to a
failure when the clone doesn't have a "master" branch.  Instead use the remote
HEAD symref as an indicator of what the primary branch is.

* guix/git.scm (resolve-reference): Support resolving symrefs.
(update-cached-checkout, latest-repository-commit): Change the default for REF
to the empty list and translate it to the remote HEAD symref.
(): Change branch field's default to #f.
(git-checkout-compiler): When branch and commit fields are both #f, call
latest-repository-commit* with the empty list as the ref.
---
 guix/git.scm | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/guix/git.scm b/guix/git.scm
index 1820036f25..5d9f0bf205 100644
--- a/guix/git.scm
+++ b/guix/git.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017, 2020 Mathieu Othacehe 
 ;;; Copyright © 2018, 2019, 2020, 2021 Ludovic Courtès 
+;;; Copyright © 2021 Kyle Meyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -209,6 +210,9 @@ (define (resolve-reference repository ref)
(let ((oid (reference-target
(branch-lookup repository branch BRANCH-REMOTE
  (object-lookup repository oid)))
+  (('symref . symref)
+   (let ((oid (reference-name->oid repository symref)))
+ (object-lookup repository oid)))
   (('commit . commit)
(let ((len (string-length commit)))
  ;; 'object-lookup-prefix' appeared in Guile-Git in Mar. 2018, so we
@@ -340,7 +344,7 @@ (define (delete-checkout directory)
 
 (define* (update-cached-checkout url
  #:key
- (ref '(branch . "master"))
+ (ref '())
  recursive?
  (check-out? #t)
  starting-commit
@@ -356,6 +360,7 @@ (define* (update-cached-checkout url
 
 REF is pair whose key is [branch | commit | tag | tag-or-commit ] and value
 the associated data: [ |  |  | ].
+IF REF is the empty list, the remote HEAD is used.
 
 When RECURSIVE? is true, check out submodules as well, if any.
 
@@ -374,6 +379,7 @@ (define* (update-cached-checkout url
 ;; made little sense since the cache should be transparent to them.  So
 ;; here we append "origin/" if it's missing and otherwise keep it.
 (match ref
+  (() '(symref . "refs/remotes/origin/HEAD"))
   (('branch . branch)
`(branch . ,(if (string-prefix? "origin/" branch)
branch
@@ -433,12 +439,13 @@ (define* (latest-repository-commit store url
(log-port (%make-void-port "w"))
(cache-directory
 (%repository-cache-directory))
-   (ref '(branch . "master")))
+   (ref '()))
   "Return two values: the content of the git repository at URL copied into a
 store directory and the sha1 of the top level commit in this directory.  The
 reference to be checkout, once the repository is fetched, is specified by REF.
 REF is pair whose key is [branch | commit | tag] and value the associated
-data, respectively [ |  | ].
+data, respectively [ |  | ].  IF REF is the empty
+list, the remote HEAD is used.
 
 When RECURSIVE? is true, check out submodules as well, if any.
 

bug#45187: git download defaults to origin/master

[Kyle Meyer]

Kyle Meyer writes:

> @@ -356,6 +360,7 @@ (define* (update-cached-checkout url
>  
>  REF is pair whose key is [branch | commit | tag | tag-or-commit ] and value
>  the associated data: [ |  |  | ].
> +IF REF is the empty list, the remote HEAD is used.

Sorry, here and ...

> @@ -433,12 +439,13 @@ (define* (latest-repository-commit store url
> (log-port (%make-void-port "w"))
> (cache-directory
>  (%repository-cache-directory))
> -   (ref '(branch . "master")))
> +   (ref '()))
>"Return two values: the content of the git repository at URL copied into a
>  store directory and the sha1 of the top level commit in this directory.  The
>  reference to be checkout, once the repository is fetched, is specified by 
> REF.
>  REF is pair whose key is [branch | commit | tag] and value the associated
> -data, respectively [ |  | ].
> +data, respectively [ |  | ].  IF REF is the 
> empty
> +list, the remote HEAD is used.

... here should say "If" rather than "IF".