bug#70174: OpenEXR is vulnerable to CVE-2023-5841 and CVE-2021-45942

[John Kehayias via Bug reports for GNU Guix]

On Thu, Apr 04, 2024 at 02:50 AM, John Kehayias wrote:

> Hello,
>
> On Thu, Apr 04, 2024 at 01:07 AM, Vinicius Monego wrote:
>
>> OpenEXR suffers from these vulnerabilities which were fixed in version
>> 3.2.2 [1] and 3.1.4 [2], respectively, while our version is currently
>> 3.1.3.
>>
>> The package contains 448 dependents, and a change in derivation
>> shouldn't be pushed to master, at least according to the patch
>> submission guidelines.
>>
>> [1] https://nvd.nist.gov/vuln/detail/CVE-2023-5841
>>
>> [2] https://nvd.nist.gov/vuln/detail/CVE-2021-45942
>
> Thanks for passing this along.
>
> I've applied a patch, attached, locally to the mesa-updates branch which
>  updates openexr to the latest version, 3.2.4. It required a few minor
>  changes (fix a phase, an input) but it builds.
>
> I may wait to queue up some more fixes for that branch, but don't
> currently have anything pending. Either way, it will be there soon and
> hopefully merged to master (just need to wait for everything to build
> and look good).
>
> Thanks!
> John

Forgot to note the change in [inputs] in the changelog, fixed locally.

bug#70174: OpenEXR is vulnerable to CVE-2023-5841 and CVE-2021-45942

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Thu, Apr 04, 2024 at 01:07 AM, Vinicius Monego wrote:

> OpenEXR suffers from these vulnerabilities which were fixed in version
> 3.2.2 [1] and 3.1.4 [2], respectively, while our version is currently
> 3.1.3.
>
> The package contains 448 dependents, and a change in derivation
> shouldn't be pushed to master, at least according to the patch
> submission guidelines.
>
> [1] https://nvd.nist.gov/vuln/detail/CVE-2023-5841
>
> [2] https://nvd.nist.gov/vuln/detail/CVE-2021-45942

Thanks for passing this along.

I've applied a patch, attached, locally to the mesa-updates branch which
 updates openexr to the latest version, 3.2.4. It required a few minor
 changes (fix a phase, an input) but it builds.

I may wait to queue up some more fixes for that branch, but don't
currently have anything pending. Either way, it will be there soon and
hopefully merged to master (just need to wait for everything to build
and look good).

Thanks!
John
From 870359351e80a3d14304a4f6a1b734f67c1ea167 Mon Sep 17 00:00:00 2001
Message-ID: <870359351e80a3d14304a4f6a1b734f67c1ea167.1712198858.git.john.kehay...@protonmail.com>
From: John Kehayias 
Date: Wed, 3 Apr 2024 22:45:50 -0400
Subject: [PATCH] gnu: openexr: Update to 3.2.4 [security fixes].

Previous versions, 3.2.2 and 3.1.4, fixed CVE-2023-5841 and CVE-2021-45942,
respectively.

* gnu/packages/graphics.scm (openexr): Update to 3.2.4.

Reported-by: Vinicius Monego 
Change-Id: I72f82e623c9b8988cae433947117cd81f40cdbc3
---
 gnu/packages/graphics.scm | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/graphics.scm b/gnu/packages/graphics.scm
index ad08141c96..188e066766 100644
--- a/gnu/packages/graphics.scm
+++ b/gnu/packages/graphics.scm
@@ -1200,7 +1200,7 @@ (define-public ogre
 (define-public openexr
   (package
 (name "openexr")
-(version "3.1.3")
+(version "3.2.4")
 (source (origin
   (method git-fetch)
   (uri (git-reference
@@ -1210,7 +1210,7 @@ (define-public openexr
   (file-name (git-file-name name version))
   (sha256
(base32
-"0c9vla0kbsbbhkk42jlbf94nzfb1anqh7dy9b0b3nna1qr6v4bh6"
+"00s1a05kggk71vfbnsvykyjc2j7y6yyzgl63sy4yiddshz2k2mcr"
 (build-system cmake-build-system)
 (arguments
  (list #:phases
@@ -1218,8 +1218,6 @@ (define-public openexr
(add-after 'unpack 'patch-test-directory
  (lambda _
(substitute* (list
- "src/test/OpenEXRUtilTest/tmpDir.h"
- "src/test/OpenEXRFuzzTest/tmpDir.h"
  "src/test/OpenEXRTest/tmpDir.h"
  "src/test/OpenEXRCoreTest/main.cpp")
  (("/var/tmp")
@@ -1247,7 +1245,7 @@ (define-public openexr
 "")
(("TEST \\(testOptimizedInterleavePatterns, \"basic\"\\);")
 "")
-(inputs (list imath zlib))
+(inputs (list imath libdeflate zlib))
 (home-page "https://www.openexr.com/;)
 (synopsis "High-dynamic-range file format library")
 (description

base-commit: 1cba1f8ce6f84c4737650401c0eb0473a45f9ff7
prerequisite-patch-id: fa1f23e1340a3eeb9f347ed719b9b0fa0558fb3f
prerequisite-patch-id: a1eb5f0955b9988d3bfe3be8403c75999a1cae5f
prerequisite-patch-id: 2889be19c4a046760f2f608cefff987b11b65a31
prerequisite-patch-id: ea93b6662275aeec1e014a9bc9fe7a96f26ac600
prerequisite-patch-id: 177440a12b7c797d22f8bb1253db133d2fbad348
prerequisite-patch-id: 3a5189c1e8e4612ceb6f1b70cc3c83e39a977eb9
prerequisite-patch-id: 7ddfa796914f078615724949db7c1ac6c148d09f
prerequisite-patch-id: 3037b56c731bc0a62c6b4a2cfecbadc8ead38453
prerequisite-patch-id: 163581597c141e701fc8089a6337683abce82894
prerequisite-patch-id: f2f116d9fedadb3443bc61ff3824c479cda5fcf0
prerequisite-patch-id: 57807814fe98a68ffc68fb9ebdb92a7115959e0b
prerequisite-patch-id: 95f518cd6bd40014a2cb1b83f5af807b069a84cf
prerequisite-patch-id: 040ecf8f843498b7bcedac335cff1b84af17fad9
prerequisite-patch-id: 06b54c27f5ecd182574be222a50f592c5fb3fa4d
prerequisite-patch-id: 50f1bd0ac736d175116893d79869780070a2ea59
prerequisite-patch-id: 03be0e6d28cd6c11eaaf7b9784ba032fa72be4ff
prerequisite-patch-id: dce4ebc8c7dc26df87b1a91f676f660a87379c8a
prerequisite-patch-id: e3f21290baa6ec82b673387974ae2561caad7e64
prerequisite-patch-id: 15f266f43c1918cc8526406283af83369c4dc80e
prerequisite-patch-id: 78eedd30786c77e0e0a06f1d959ee9b687902d8f
prerequisite-patch-id: 3ad571d4975f17216c7ab008f3e81c5e038ec65b
prerequisite-patch-id: 8bcf03f489b2f139d277d0e46552ac0211b061b2
prerequisite-patch-id: 0e92576d6b767e75d64accf5b5d38eda08dae78e
-- 
2.41.0

bug#70174: OpenEXR is vulnerable to CVE-2023-5841 and CVE-2021-45942

[Vinicius Monego]

OpenEXR suffers from these vulnerabilities which were fixed in version 
3.2.2 [1] and 3.1.4 [2], respectively, while our version is currently 3.1.3.


The package contains 448 dependents, and a change in derivation 
shouldn't be pushed to master, at least according to the patch 
submission guidelines.


[1] https://nvd.nist.gov/vuln/detail/CVE-2023-5841

[2] https://nvd.nist.gov/vuln/detail/CVE-2021-45942

bug#70170: emacs-strait-el: build failure

[Christopher Howard]

Hello, after a recent guix pull, I am getting a failure when building 
emacs-straight-el.

```
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure stat: No such file or directory: 
"/tmp/guix-build-emacs-straight-el-0-2.039e5c9.drv-0/source/tests/mocks/.emacs.d/straight/build/straight-mock-repo/straight-mock-repo.el"
```

Here is my system information:

```
christopher@theoden 
--- 
OS: Guix System x86_64 
Host: OptiPlex 9020 00 
Kernel: 6.7.10-gnu 
Uptime: 8 days, 2 hours, 10 mins 
Packages: 99 (guix-system), 251 (guix-user) 
Shell: bash 5.1.16 
Resolution: 1920x1080 
DE: GNOME 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: shepherd 
CPU: Intel i5-4570 (4) @ 3.600GHz 
GPU: AMD ATI Radeon HD 8490 / R5 235X OEM 
GPU: Intel HD Graphics 
Memory: 4260MiB / 7863MiB 
```

```
Generation 62   Apr 02 2024 11:03:41(current)
  guix e82dc38
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e82dc389f58f3f2de1ba65fcd1d7584908ab5a14
```

-- 
 Christopher Howard
 gemini://gem.librehacker.com
 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ


bingQgWA2OFbe.bin
Description: application/gunzip

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[pelzflorian (Florian Pelz)]

My apologies for not giving a good response.

Yes, the issue you mention is indeed different from a record ABI
mismatch, in that the error message for an ABI message says
“recompilation needed” and is documented in the manual, unlike the
problematic error message that you reported.

Adding a note to doc/guix.texi would target the wrong audience, though,
because every Guix developer needs to rerun ./bootstrap, not only the
developer who added the translation.

The error message you reported

automake-1.16: error: cannot open < ./doc/guix-cookbook.pt_BR.texi: No
such file or directory

can be traced with “make --trace”.  It is because the
Autotools-generated Makefile recognizes that doc/local.mk has changed
and therefore runs “automake-1.16 --gnu Makefile”, which scans for the
Texinfo files mentioned in info_TEXINFOS and cannot open the mentioned
file.

Currrently the file “bootstrap” is a script that creates
“doc/guix.${lang}.texi” stub files.  When you don’t run “bootstrap”, the
files are missing.

At first sight, instead of creating the stub files in “bootstrap”, files
with

@setfilename guix.pt_BR.info
@include version-pt_BR.texi

for all languages could be pushed to guix.git by the developer who adds
the translation.  However, this is not enough, because “bootstrap” still
must run “touch po/doc/guix-manual.eo.po”, otherwise the PO4A rule to
create “doc/version-pt_BR.texi” is not run by GNU Make.

So there is no solution, is there?

Regards,
Florian

bug#70111: [PATCH] gnu: gnome-essential-extras: Propagate xdg-desktop-portal.

[Maxim Cournoyer]

Hello,

Dariqq  writes:

> xdg-desktop-portal (and xdg-desktop-portal-gnome) is needed for the dark theme
> in Gnome 44 to work properly.
>
> * gnu/packages/gnome.scm (gnome-essential-extras)[propagated-inputs]: Add 
> xdg-desktop-portal.
>
> Change-Id: Id84626e6bc404e9607ee7f8f299ac90f24323081

Reviewed-by: Maxim Cournoyer 

Haven't tested it myself, but I trust the findings of Dariqq.

-- 
Thanks,
Maxim

bug#70051: guix system hangs on boot with LUKS /home partition

[Adrien 'neox' Bourmault]

I can confirm aurtzy's patch works (just tested on top of
7af70efd7633b0d70091762cf43ce01a86176e8e)

bug#56611: Build failure of font-abattis-cantarell@0.303 due to test fail fontPens.penTools.estimateQuadraticCurveLength

[Maxim Cournoyer]

Hi,

Jacob Hrbek  writes:

> === FAILURES
> ===
> ___ [doctest] fontPens.penTools.estimateQuadraticCurveLength
> ___
> 155
> 156 Estimate the length of this curve by iterating
> 157 through it and averaging the length of the flat bits.
> 158
> 159 >>> estimateQuadraticCurveLength((0, 0), (0, 0), (0, 0)) #
> empty segment
> 160 0.0
> 161 >>> estimateQuadraticCurveLength((0, 0), (50, 0), (80, 0)) #
> collinear points
> 162 80.0
> 163 >>> estimateQuadraticCurveLength((0, 0), (50, 20), (100, 40))
> # collinear points
> Expected:
>     107.70329614269009
> Got:
>     107.70329614269008
>
> /tmp/guix-build-python-fontpens-0.2.4.drv-0/fontPens-0.2.4/Lib/fontPens/penTools.py:163:
> DocTestFailure

The problem was reported by Tobias at
https://github.com/robotools/fontPens/issues/41 and disabled in Guix
with commit 212ca81895b2baa819ea11a308ad21880b84a546.

Closing.

-- 
Thanks,
Maxim

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Hilton Chain via Bug reports for GNU Guix]

Hi,

I have /var/run and /run on separate file systems, recently I noticed system
reconfiguration stopped with "guix system: error: rename-file: Invalid
cross-device link":

--8<---cut here---start->8---
newfstatat(AT_FDCWD, "/run", {st_mode=S_IFDIR|0755, st_size=440, ...}, 
AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/run/dbus", {st_mode=S_IFDIR|0700, st_size=40, ...}, 
AT_SYMLINK_NOFOLLOW) = 0
mkdir("/run", 0777) = -1 EEXIST (File exists)
mkdir("/run/dbus", 0777)= -1 EEXIST (File exists)
chown("/run/dbus", 988, 983)= 0
chmod("/run/dbus", 0755)= 0
symlink("/run/dbus", "/var/run/dbus")   = -1 EEXIST (File exists)
readlink("/var/run/dbus", 0x1634730, 100) = -1 EINVAL (Invalid argument)
openat(AT_FDCWD, "/var/run/dbus", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 
17
newfstatat(17, "", {st_mode=S_IFDIR|0755, st_size=80, ...}, AT_EMPTY_PATH) = 0
getdents64(17, 0x16dfe10 /* 4 entries */, 32768) = 112
rename("/var/run/dbus/system_bus_socket", "/run/dbus/system_bus_socket") = -1 
EXDEV (Invalid cross-device link)
close(13)   = 0
write(2, "\33[1m\33[0mguix system: error: rena"..., 67guix system: 
error: rename-file: Invalid cross-device link
) = 67
exit_group(1)   = ?
+++ exited with 1 +++
--8<---cut here---end--->8---

It's because /var/run/dbus was used for dbus service before, and now migration
to /run/dbus is done with ‘rename-file’:

--8<---cut here---start->8---
(rename-file (string-append "/var/run/dbus/" next)
 (string-append "/run/dbus/" next))
--8<---cut here---end--->8---

I think the logic can be improved for this case, but not sure how at the moment.
What do you think?

Thanks

bug#70164: home-bash-service default PS1 overwrites .bashrc PS1 in login shells

[Richard Sent]

Hi Guix!

A common convention for where to set PS1 is in .bashrc, not
.bash_profile [1-3]. Unfortunately home-bash-service doesn't support this
convention for login shells.

home-bash-service generates a default .bash_profile that follows these
steps:

1. Source .profile
2. Source .bashrc
3. Set PS1 if guix-defaults? is truthy

This means that any PS1 configuration in .bashrc is overwritten by
.bash_profile for login shells specifically.

This is visible in a TTY, but also in WSL, which defaults to opening a
login shell. PS1 will be Guix's predefined value instead of the value
set in .bashrc.

Setting guix-defaults? to #f has many side effects, so I don't feel that
is a valid solution.

A comment in home/serivces/shells.scm suggests setting PS1 via
environment-variables since that is appended to the end of
.bash_profile. This is fine for simple prompts, but complicated prompts
are often split apart into separate bash functions and variables. Either
an implicit dependency between .bashrc and .bash_profile is created, or
.bash_profile balloons into a mega-file while the conventional wisdom is
to keep it as simple as possible.

environment-variables also exports PS1, causing it to become an
environment variable, not a shell variable. This might cause some odd
behavior when subprocesses inherit it. [4]

Some possible solutions:

1. Move default PS1 to bashrc, right after serializing %default-bashrc
2. Keep default PS1 in .bash_profile, but before loading .bashrc
3. Add a set-prompt? field to home-bash-configuration

Of the 3, I think 1 is the best and plan to submit a patch for it soon.
I'm opening the bug in case anyone thinks I missed something.

[1] https://unix.stackexchange.com/a/549075
[2] https://superuser.com/a/789465
[3] https://superuser.com/a/789454
[4] https://unix.stackexchange.com/a/44000

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[Rostislav Svoboda]

Hi Florian,

> This advice [...] I don’t think [...] it is worth the notification [...]

It ate me away ~1 work-hour, from the "It doesn't compile, what the
hell!?!" moment, all the way through the "What am I doing wrong?...
Nothing!" phases, until I found the culprit. And then the search for a
solution... in vain. So I wrote a bug report. Then it ate some 3
minutes from Efraim's time and 10 minutes of yours, I guess, and now
15 minutes of mine again.

And this will repeat basically every time we add a new language.
Currently, we're at 7 for the manual and 6 for the cookbook. Adding 5
new in each... In short, this is going to cost us 1 or 2
person-work-days, I estimate. And the indirect costs may be much
higher. E.g. if somebody thinks "I'm going to learn Guix while
translating it to my mother language" trips over this, well then he or
she may just throw it all away in frustration. Ups.

> also, many would not read it.

Except, it will be picked up by search engines and the AI(!):

Q: Hello, ChatGPT, tell me, am I the most handsome on this planet and
why doesn't the `make doc/guix.texi` compile? Somebody added a new
language and... it doesn't work anymore. Grrrh!
A: Oh well, you just need to rerun `./bootstrap` and `./configure`
when a new language is added to the Guix manual or cookbook. And the
most handsome on this planet? Forward-thinking people, kind enough to
write things down, so that others like me and you can learn from them.

Cheers, Bost

bug#70121: [PATCH] gnu: emacs-magit: Fix generation of autoloads.

[Clément Lassieur]

On Wed, Apr 03 2024, Clément Lassieur wrote:

> On Mon, Apr 01 2024, Liliana Marie Prikler wrote:
>
>> * gnu/packages/emacs-xyz.scm (emacs-magit)[#:phases]: Replace 
>> ‘make-autoloads’
>> like the others.
>>
>> Fixes: Magit autoloads are missing 
>> ---
>
> Hi,
>
> Tested, looks good to me.

Pushed, thanks.

bug#70121: [PATCH] gnu: emacs-magit: Fix generation of autoloads.

[Clément Lassieur]

On Mon, Apr 01 2024, Liliana Marie Prikler wrote:

> * gnu/packages/emacs-xyz.scm (emacs-magit)[#:phases]: Replace ‘make-autoloads’
> like the others.
>
> Fixes: Magit autoloads are missing 
> ---

Hi,

Tested, looks good to me.

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[pelzflorian (Florian Pelz)]

Hello Rostislav,

This advice would not be read by most affected Guix developers.  The
problem is that every guix developer must rerun ./bootstrap and
./configure on pulling certain changes like ABI breaks (when a new
record is added) and new cookbook versions.

Every Guix developer making a breaking change could put a notice
somewhere where it can be displayed from a pull hook, if that is
possible, but I don’t think developers would remember or that it is
worth the notification, also many would not read it.

Regards,
Florian

bug#70111: [PATCH] gnu: gnome-essential-extras: Propagate xdg-desktop-portal.

[Dariqq]

xdg-desktop-portal (and xdg-desktop-portal-gnome) is needed for the dark theme
in Gnome 44 to work properly.

* gnu/packages/gnome.scm (gnome-essential-extras)[propagated-inputs]: Add 
xdg-desktop-portal.

Change-Id: Id84626e6bc404e9607ee7f8f299ac90f24323081
---
 gnu/packages/gnome.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index c8305b0dd8..7209a14e67 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -10306,6 +10306,7 @@ (define-public gnome-essential-extras
 pulseaudio
 shared-mime-info
 system-config-printer
+xdg-desktop-portal
 xdg-user-dirs
 yelp
 zenity))

base-commit: f26b42f6c07a00dd2cecb006846e672b88748b84
-- 
2.41.0

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

[Ludovic Courtès]

Ludovic Courtès  skribis:

> The ‘cuirass remote-server’ process goes awry when misbehaved clients
> connect; specifically, some of its fibers crash, leaving it running but
> inactive:
>
> 2023-12-04 10:13:14 periodic update: 0 resumable, 0 failed builds
> 2023-12-04 10:13:28 error: Connection reset by peer when replying to 
> xx.xx.xx.254.
> 2023-12-04 10:13:42 error: invalid log received from xx.xx.xx.254
> 2023-12-04 10:13:42 error: EOF while receiving log from xx.xx.xx.254
> 2023-12-04 10:13:48 Uncaught exception in task:
> 2023-12-04 10:13:48 In fibers.scm:
> 2023-12-04 10:13:48186:20  8 (_)
> 2023-12-04 10:13:48145:21  7 (_)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1752:10  6 (with-exception-handler _ _ #:unwind? _ 
> #:unwind-for-type _)
> 2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
> 2023-12-04 10:13:48695:11  5 (_)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1747:15  4 (with-exception-handler # 7f982c2abd50 at ice-9/boot-9.scm:1831:7 (exn)> _ #:unwind? _ 
> #:unwind-for-type _)
> 2023-12-04 10:13:48 In cuirass/scripts/remote-server.scm:
> 2023-12-04 10:13:48437:23  3 (serve-build-requests _ #< getq: 
> # 
> #))> getq-gc-co
> unter: # putq: # value: (())> putq-gc-counter: #>)
> 2023-12-04 10:13:48 In cuirass/remote.scm:
> 2023-12-04 10:13:48 466:6  2 (receive-message _ #:router? _)
> 2023-12-04 10:13:48 In ice-9/boot-9.scm:
> 2023-12-04 10:13:48   1685:16  1 (raise-exception _ #:continuable? _)
> 2023-12-04 10:13:48   1685:16  0 (raise-exception _ #:continuable? _)
> 2023-12-04 10:13:48 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2023-12-04 10:13:48 Throw to key `match-error' with args `("match" "no 
> matching pattern" (# # 
> #))'.

With commit 9a1452ee021c9f773424961cfeef47ca0b7c5c5a, ‘cuirass
remote-server’ handles this situation gracefully.

I’m still curious about who’s sending us garbage: it has to be valid
zmq, just with the wrong number of parts.  From the logs, it seemed like
a port scanner or something on the MDC network was sending garbage on
all the open ports, but that would need to be a sophisticated one.

Ludo’.

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> The ‘cuirass remote-server’ process goes awry when misbehaved clients
>> connect; specifically, some of its fibers crash, leaving it running but
>> inactive:
>
> I guess what I reported in bug#67633 is a symptom of the above problem,
> perhaps?

It could be yes, if ‘remote-server’ crashed right at that moment.

Ludo’.