GNOME Bugzilla – Bug 644049
fix nssckbi search path
Last modified: 2021-05-19 12:27:29 UTC
Created attachment 182641 [details] [review] fix nssckbi search path Hey, it seems that the nssckbi search function in evolution has some issue and causes NSS problems in few occasions. I had multiple bug reports on Debian: http://bugs.debian.org/616587 http://bugs.debian.org/563253 http://bugs.debian.org/563324 and the attached patch (from Mike Hommey, the nss maintainer) seems to fix the problem. Could you look at it and comment?
Passing a NULL module path is always wrong because NSS may be installed in a non-standard directory. The library path must come from nss.pc. We already check the libdir variable from nss.pc. If libdir is not appropriate for libnssckbi then nss.pc needs to supply a variable that is.
> Passing a NULL module path is always wrong because NSS may be installed in a > non-standard directory. If NSS is installed in a non-standard directory, most likely LD_LIBRARY_PATH will point there, and the library loading will just work™. I have a patch that I should get landed on nss that also makes it even safer in that the module is loaded from wherever nss knows it was loaded from, thus not relying on LD_LIBRARY_PATH. > The library path must come from nss.pc. We already check the libdir variable > from nss.pc. If libdir is not appropriate for libnssckbi then nss.pc needs > to supply a variable that is. And hardcoding the path from a variable at build time also means you're always going to use the same libnssckbi, even if, say, the user installs a newer nss in /usr/local/lib and evolution was built against an nss in /usr/lib.
(In reply to comment #2) > And hardcoding the path from a variable at build time also means you're always > going to use the same libnssckbi, even if, say, the user installs a newer nss > in /usr/local/lib and evolution was built against an nss in /usr/lib. Correct, that's the behavior we want. Evolution would need to be rebuilt against the newer nss then.
Does t(In reply to comment #3) > (In reply to comment #2) > > And hardcoding the path from a variable at build time also means you're always > > going to use the same libnssckbi, even if, say, the user installs a newer nss > > in /usr/local/lib and evolution was built against an nss in /usr/lib. > > Correct, that's the behavior we want. > > Evolution would need to be rebuilt against the newer nss then. Uh, does this mean we should ask for an evolution rebuild everytime nss is upgraded?
Of course not. Mike was asking about installing a second nss into a different prefix and expecting Evolution to pick that up automatically. We don't do that. That would require a rebuild.
And even rebuilt, evolution will be picking the old libnssckbi.so because its full path will be harcoded in ~/.pki/nssdb/pkcs11.txt because of the evolution initialization. Using a file name without a path will make pkcs11.txt only contain the file name, making it work later with a different nss.
Hardcoding the path of the module/library is also breaking multi-arch on Debian library=/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so name=Mozilla Root Certs NSS=trustOrder=100 If I'm not wrong that means that any 32bits application using NSS will try to load the 64bit module, I'm not sure this is going to end well for them
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.