Subject: [bug#75688] [PATCH 0/2] Introduce GUIX_LIBRARY_PATH to replace harmful environment variables

From: Maxim Cournoyer <[email-masked]>
Date: Wed, 22 Jan 2025 10:03:09 +0900

Hello,

宋文武 <[email-masked]> writes:

[...]

>> inheriting its parent environment, but otherwise I'm not sure I
>> understand the issue, especially how processing a .VARIABLE file instead
>> would handle this better?  Could yo give an example?
>
> A program try to load different versions of plugins via
> GIO_EXTRA_MODULES, QT_PLUGIN_PATHS could crash due to ABI incompatible, see:
>
> mix Qt 5.9.3 and 5.9.4: https://yhetil.org/guix/[email-masked]/
> mix GIO modules with different glibc: https://yhetil.org/guix/[email-masked]/
>
> In a desktop environment, with wrapper scripts you would get
> GIO_EXTRA_MODULES, GTK_PATH contains store paths:
>
> https://yhetil.org/guix/[email-masked]/
>
> GIO_EXTRA_MODULES=/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/gnu/store/knm6b1dxg2j3vji4wrgngv99pvb6f5ff-glib-networking-2.70.0/lib/gio/modules::/run/current-system/profile/lib/gio/modules
> GTK_PATH=/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/lib/gtk-3.0:/gnu/store/fkl4fg06f538ryhiw4bs2iwwfs56g2k3-libcanberra-0.30/lib/gtk-3.0

I see; I agree that if the environment variables or not set by a search
path and instead picked up by the binary from some file, then it solves
this class of problem, but that seems equivalent to wrapping the
binaries, no?  You'd still have some glue code reading .VARIABLE and
then doing a bunch of setenv before launching the actual program, no?
That glue code is currently the shell or Guile script used to wrap the
binaries.

Unless we can fully eliminate search paths and propagation, we'll still
have the issue of having environment variables being set, even with the
use of .VARIABLE, as far s I understand.

> Then when you try to run a incompatible program (eg: with a newer glibc
> or gtk), those variables leaks from wrapper scripts will make the
> program crash.
>
> By replace those variables via .VARIABLE file, those starts with

nitpick: Perhaps it could be called .environment or
.environment-variables, similarly named as in our failed Guix builds.

[...]

As you can see, perhaps I'm still missing pieces of your big picture.  a
RFC/GCD documenting the idea, or a demo implementation if that's
easier/faster would help (code is often more succinct than text).

-- 
Thanks,
Maxim