Re: Core-updates coordination and plans

[Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

Hi Josselin,

On Wed, Jan 31 2024, Josselin Poiret wrote:

> One conundrum we have for now: glibc 2.38 has a couple of new CVEs

The authors describe CVE-2023-6246, which is probably the most serious
of the four vulnerabilities, as "significant" [1] and Red Bat ranks it
as "8.4 (HIGH)" under the new CVD scale. [2]

Most important, "This flaw allows local privilege escalation, enabling
an unprivileged user to gain full root access, as demonstrated in Fedora
38." [again, 1]

> we have three options:
> 1) change glibc to track the 2.38 release branch → world rebuild.
> 2) graft glibc → bad user experience (and we're not supposed to graft
> outside of master).
> 3) switch to 2.39 → world rebuild + possibly more work fixing new build
> failures.

Personally, I would go straight to Glibc 2.39.

I am not sure it's helpful to obsess about "world rebuilds." The fear
and cost of rebuilding in Guix is real, but it is a necessary
consequence of the way Guix works. The fear is also a dominant and
persistent mental obstacle to making Guix better. [3]

> I'd ideally prefer 3 but we don't know yet if there is going to be a
> lot of breakage

Your argument that more work may be needed is well-placed, however.. We
won't know until we get there. Perhaps we can revert to version 2.38
prior to your merge if the problems are severe.

> glibc 2.39 should hopefully release tomorrow (01/02/2024)

Fortunately, your merge schedule conincides more or less with Glib's
release cycle. There should be plenty of data from around the world
about the new Glibc version's performance in two or three weeks.

> most of the patches ... got pushed, are there any other ... ?

I don't know whether eudev is a core-package but I personally find it
irresponsible that my patch to fix the use of MAC-based addresses for
network interfaces [4][5] has not been accepted in some form.

In a functional OS like Guix, no administrator should rely on device
enumerations provided by the BIOS, by UEFI or by the Linux kernel. The
fix is a one-liner. [6]

I used 'regexp-quote' to avoid Guile's quoting madness. [7] As an
alternative, we could quote the literals with the old Perl::Critic trick
that avoids escapes for metacharacters: [8]

  (substitute* "src/udev/Makefile.am"
    (("[$][(]udevrulesdir[)]") "/etc/udev/rules.d"))

Either way, I'd appreciate if Eudev could please be fixed in this
core-updates cycle. The fix has been available for more than half a
year.

The fix was furthermore deployed on all my systems, including the one
running the test deployment of Debbugs in Guix, which is available at
debbugs.juix.org. The fix works. Thanks!

Kind regards
Felix

[1] https://blog.qualys.com/vulnerabilities-threat-research/2024/01/30/qualys-tru-discovers-important-vulnerabilities-in-gnu-c-librarys-syslog
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-6246
[3] https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00243.html
[4] https://issues.guix.gnu.org/63508
[5] https://issues.guix.gnu.org/63787
[6] https://issues.guix.gnu.org/63508#12-lineno51
[7] https://www.gnu.org/software/guile/manual/html_node/Backslash-Escapes.html
[8] https://metacpan.org/pod/Perl::Critic::Policy::RegularExpressions::ProhibitEscapedMetacharacters