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

From: 宋文武 <[email-masked]>
Date: Wed, 22 Jan 2025 17:42:44 +0800

Maxim Cournoyer <[email-masked]> writes:

> 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?
Well, wrapping solve it in one way, since we use 'prefix' in wrapper,
eg: konsole has:

export QT_PLUGIN_PATH="/gnu/store/.../lib/qt6/plugins${QT_PLUGIN_PATH:+:}$QT_PLUGIN_PATH"

which let konsole work in a environment which has an incompatible
QT_PLUGIN_PATH, since the incompatible one load last and applications
only load a named plugin once.

It dosen't work other way, that in konsole when you run an another
unwrapped application, can be influenced by QT_PLUGIN_PATH from
konsole's wrapper script.

> 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.

The point for those .VARIABLE files is without wrapper scripts there're
no setenv call anymore, ensure that getenv only get profiles paths, in
another words: reading from file and apply the values replaced setenv
then getenv and apply the values.

>
> 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.

Well, we must have environment variables due to we want to mix profiles.
Search paths can be applied without environment variables, by using
.VARIABLE files for hardcoded dependencies; and by finding current
profile path from executable (lookup argv[0] in PATH), from current
profile path we can construct and apply search paths values.

Use GUIX_* would solve problems for foreign programs, then reduce
wrapper scripts would solve some problems for guix programs.

Disallow load plugins from different profiles will solve more remaining
problems, but this can be considered later if there are actually reports.

>> 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.

Those are not variables in the "environment", but search-path values
hardcoded for the specified binary.  Maybe I should use one set of files
for all binaries in one output like 'etc/ld.so.cache' does tough.
Compare with use one ".environment-variables" file, use different files
for each variable value simplify the logic and be more efficiency.

How about /etc/search-paths.d/VAR1, /etc/search-paths.d/VAR2?
Need more logic to get "etc", and add it to %harmless-collisions for
union-build though.

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

Sure, I'll work on implementation this.  Thank you!