bug#47458: Terrible UX upgrading Emacs in Guix

Hi Leo! Leo Prikler writes: > With this, the search path specification of EMACSLOADPATH does no longer > depend on the version of Emacs, which should make upgrading major versions > less painful. See also: > - > - > > * gnu/packages/emac

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

Hi Ludovic! Ludovic Courtès writes: > I just noticed this: > > $ guix size ktouch | tail -1 > total: 1752.4 MiB > > > Sounds a lot for a touch typing tutor. > > Turns out ktouch references all its build-time dependencies: gcc, > glibc:static, binutils, findutils, everything. It comes from the >

bug#47496: Very slow `guix environment -l nyxt/build-scripts/guix.scm

Hi, On +2021-04-03 20:42:08 +0200, Pierre Neidhardt wrote: > I just tried the following: > > --8<---cut here---start->8--- > guix environment -l ... > --8<---cut here---end--->8--- > > was forever until I stopped it. > Then

bug#47141: Zabbix packages vulnerable to CVE-2021-27927

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

bug#47587: 'guix system edit' subcommand

Hello! Like 'guix edit hello' we could have 'guix system edit screen-locker' for easy access to customize services. What do you think? Is this hard to do? Léo signature.asc Description: This is a digitally signed message part

bug#47573: make check-system fails on master

It seems running 'make clean' then 'make check-system' again solved the issue. Probably some build system inconsistency issue. signature.asc Description: This is a digitally signed message part

bug#47578: bug found running guix pull

Okay, glad to hear it, and thank you for reporting it! I'm closing this bug now but please send another message if the problem happens again while running the new guix-daemon. On Sat, Apr 03, 2021 at 03:16:59PM -0500, Nathan Dehnel wrote: > Yes, it worked after several tries. > > On Sat, Apr 3

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

Hi Julien, Julien Lepiller writes: > We should probably fix ibus so it regenerates its cache when it's a > different process. It could be as simple as using a subdirectory > computed from the absolute name of the ibus binary, maybe. Would you like to try? I won't be able to work more on this bu

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

Maxime Devos skribis: > +The attack consists of the user being logged in after the account > +skeletons have been copied to the home directory, but before the > +owner of the account skeletons have been set. The user then deletes > +a copied account skeleton (e.g. `$HOME/.gdbinit`) and replaces

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

Maxime Devos skribis: > From 7937b9f18085569e5d7cb8a3c4dc08e1088a94a9 Mon Sep 17 00:00:00 2001 > From: Maxime Devos > Date: Sat, 3 Apr 2021 18:02:05 +0200 > Subject: [PATCH] =?UTF-8?q?website:=20Add=20post=20about=20vulnerability?= > =?UTF-8?q?=20in=20=E2=80=98copy-account-skeletons=E2=80=99.?=

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

Maxime Devos skribis: > The attack consists of the user being logged in after the account > skeletons have been copied to the home directory, but before the > owner of the account skeletons have been set. The user then deletes > a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces

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

Note that this issue is about Guix System; users of Guix on other distros are unaffected. Maxime Devos skribis: > The attack consists of the user being logged in after the account > skeletons have been copied to the home directory, but before the > owner of the account skeletons have been set.

bug#47578: bug found running guix pull

Yes, it worked after several tries. On Sat, Apr 3, 2021, 12:19 PM Leo Famulari wrote: > On Sat, Apr 03, 2021 at 12:41:10AM -0500, Nathan Dehnel wrote: > > ERROR: > > 1. &nar-error: > > file: #f > > port: # > > guix pull: error: You found a bug: the program > > '/gnu/store/w6596kfg5

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

Hi Maxime, Maxime Devos skribis: > From 9672bd37bf50db1e0989d0b84035c4788422bd31 Mon Sep 17 00:00:00 2001 > From: Maxime Devos > Date: Tue, 30 Mar 2021 22:36:14 +0200 > Subject: [PATCH 1/2] activation: Do not dereference symlinks in home directory > creation. > MIME-Version: 1.0 > Content-Type

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

Pierre Neidhardt writes: > Wow, that was fast, thank you Mark! > > Any idea how I can test this, i.e. how I can force a graft? Just apply the patch to a git checkout of Guix, build it, and then use it to build anything you like, e.g. "./pre-inst-env guix build nyxt". With this patch applied, al

bug#47578: bug found running guix pull

On Sat, Apr 03, 2021 at 12:41:10AM -0500, Nathan Dehnel wrote: > ERROR: > 1. &nar-error: > file: #f > port: # > guix pull: error: You found a bug: the program > '/gnu/store/w6596kfg55g578dvwaayfj7alq7g88j0-compute-guix-derivation' > failed to compute the derivation for Guix (version:

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

On Sat, 2021-04-03 at 18:22 +0200, Maxime Devos wrote: > +;; It is important 'chown' is called after > 'copy-account-skeletons' > +;; Otherwise, a malicious user with good timing could > +;; create a symlink in HOME that would be dereferenced by > +;

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

A suggested blog post is attached. From 7937b9f18085569e5d7cb8a3c4dc08e1088a94a9 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sat, 3 Apr 2021 18:02:05 +0200 Subject: [PATCH] =?UTF-8?q?website:=20Add=20post=20about=20vulnerability?= =?UTF-8?q?=20in=20=E2=80=98copy-account-skeletons=E2=80=99.?

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

Patch is attached. The committer will need to change the commit id appropriately. From 9672bd37bf50db1e0989d0b84035c4788422bd31 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Tue, 30 Mar 2021 22:36:14 +0200 Subject: [PATCH 1/2] activation: Do not dereference symlinks in home directory creation

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

A TOCTTOU (time-of-check to time-of-use) vulnerability has been found in the activation code of user accounts, more specifically in the code that copies the account skeletons. * Vulnerability The attack consists of the user being logged in after the account skeletons have been copied to the home

bug#47570: libvirt still embeds full path to qemu-system in saved .xml files

On Fri, 2021-04-02 at 22:41 +0200, divoplade wrote: > Hello, > > I tried to add my comment to issue 31365, but it has been archived and > made read-only. > [...] For future reference: it is possible to unarchive and reopen issues. I don't recall the exact procedure, but when sending a mail to 31

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

On Sat, 2021-04-03 at 03:12 -0400, Mark H Weaver wrote: > [...] > > The following ungrafted libraries are loaded by processes from the > mysterious old version of 'ibus' on my system: glib, cairo, and libx11. > I still have no clue where the reference to that mysterious old version > (/gnu/store/a

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

Oh! That would explain why I had so much trouble fixing/updating ibus and ibus-anthy! We should probably fix ibus so it regenerates its cache when it's a different process. It could be as simple as using a subdirectory computed from the absolute name of the ibus binary, maybe. Le 3 avril 2021

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

I wrote: > I still have no clue where the reference to that mysterious old version > (/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming > from. I found them: ~/.cache/ibus/bus/registry /var/lib/gdm/.cache/ibus/bus/registry On my system, those files include absolute pathnames

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

Earlier, I wrote: > Looking for references to the old 'glib' was the *first* thing I > checked. I haven't yet checked anything else, so I don't know how > widespread this problem is. I looked for other ungrafted libraries loaded on my system, and I'm glad to report that I see no evidence of any g