Ludovic Courtès <l...@gnu.org> writes: > 宋文武 <iyzs...@envs.net> skribis: > >> ld.so.cache >> search-paths.d >> GUIX_XDG_DATA_DIRS >> GUIX_GIO_EXTRA_MODULES >> GUIX_GTK4_PATH > > I don’t think the “GUIX_” prefix is really justified in the proposal.
Sure. There are 2 reasons, one is to avoid broke foreign systems ( GUIX_GIO_EXTRA_MODULES, GUIX_GTK4_PATH), another is about priority (GUIX_XDG_*) I'll explain later. > > There’s a precedent, ‘GUIX_PYTHONPATH’, but I think it does not follow > that this can be generalized to every search path environment variable. > > For example, the XDG_ variables are honored by a lot of software, not > just GLib- or Qt-based software, and it’s unrealistic to patch them all. > It’s also undesirable: generally speaking, we want to stay as close to > upstream as possible so that documentation, tutorials, and scripts found > elsewhere also work on Guix. Yes, we introduced GUIX_PYTHONPATH, GUIX_GTK* to avoid ABI incompatibility problems between different programs from foreign systems and Guix systems. But XDG_DATA_DIRS, as it's designed for shareable data files, won't have ABI incompatibility problems, and we rely on it for a foreign desktop launch to find applications (via desktop files), fonts installed from Guix. So do we need 'GUIX_XDG_*'? Well, In 'wrap-program' we can specifiy how the wrapped environment variables are going to be combined with the system level variables in 3 positions: prefix, suffix or = (exact). The priority between wrapped and system level variables influence the robustness of programs. For plugins which might have ABI problems, we'll use 'prefix', so a wrapped program always load the correct ones (eg: qtbase) first, and hopefully they can ignore the possible incompatible ones (eg: a qt theme plugin) with reduced functions but still works. Or for not real search paths which only support a single directory or file, we'll use '=' (eg: SSL_CERT_FILE). But for XDG_DATA_DIRS and XDG_CONFIG_DIRS, we'll want to use 'suffix', so that the shared combined data (icons, mime databases) will be used instead of a seperated incomplete ones. Also it allow user to customize them as usually, or 'guix home' or 'guix system' to custom them at profile level. In the specified search-paths.d implementation, for simplify reason, the envs from search-paths.d files are always used in 'prefix' way. For '=' cases, we could patch it to a real search path (eg: GUIX_GDK_PIXBUF_MODULE_FILES), or hardcode it (eg: QTWEBENGINEPROCESS_PATH #75966). For 'suffix' cases, it uses 2 variables, that's prefer XDG_DATA_DIRS (set by profile or foreign system) over GUIX_XDG_DATA_DIRS (set by search-paths.d, not leaking). > >> ## Find the location of the current executable >> >> To find its search path configuration files when an executable is running, >> we can first find the location of the executable. Conveniently, Linux >> provides a pseudo-file `/proc/self/exe` for this exact purpose, which works >> well for ELF executables. But for an interpreter script, `/proc/self/exe` >> would return the file name of its interpreter instead of the script, so >> we patch interpreters to set 2 environment variables: >> >> - `GUIX_INTERPRETER_FILE`: absolute file name of the interpreter >> - `GUIX_MAIN_SCRIPT_FILE`: absolute file name of the script > > We won’t patch every interpreter out there, that’s not reasonable. Yes, python should be the most, also we can avoid patching and still use 'wrap-program' for them. > > These two variables could also have unexpected consequences since an > attacker could override them to cause confusion. The check (current /prof/self-exe == GUIX_INTERPRETER_FILE) done in the client side should prevent the attack or confusion, if the interpreter haven't changed then there should be no way to modify GUIX_MAIN_SCRIPT_FILE set by the interpreter. > [...] > > I’m concerned about the cost of maintaining these patches. Again, the > ld.so patch (for glibc) sets a precedent, but this part of glibc changes > relatively rarely, and it’s just one patch; what if we have to maintain > ten such patches in big and changing libraries like GLib and Qt? I'm totally fine with reject the implementation due to maintaince burden. I could polish the patches later for easier review and decide they are reasonable or not. > > Overall, I think I’d be reassured if we reduced the scope a little bit: > don’t insist on the “GUIX_” prefix, focus on GTK and Qt applications. Okay, I'll send GUIX_GIO_EXTRA_MODULES as a seperated patch later. For 'GUIX_XDG_DATA_DIRS' and 'GUIX_XDG_CONFIG_DIRS', do you think the current implementation plan (GUIX_ ones only used by search-paths.d, only XDG_DATA_* still set by profile and visible, use 2 variables due to simplify reason) fine? Thank you!
