Apache OpenOffice (AOO) Bugzilla – Issue 104554
xmlsecurity: loading of root certificate with S
Last modified: 2017-05-20 11:33:40 UTC
I made changes to the code with loads the root certificate module and noticed that this would probably not work when "SYSTEM_MOZILLA" is used. Please check the code in xmlsecurity/source/xmlsec/nss/seinitializer_nssimpl.cxx:nsscrypto_initialize The code change was made on cws jl127 and will probably integrated in DEV300m57. This is the my comment from the source file: //Older versions of Firefox (FF), for example FF2, and Thunderbird (TB) 2 write //the roots certificate module (libnssckbi.so), which they use, into the //profile. This module will then already be loaded during NSS_Init (and the //other init functions). This fails in two cases. First, FF3 was used to create //the profile, or possibly used that profile before, and second the profile was //used on a different platform. // //Then one needs to add the roots module oneself. This should be done with //SECMOD_LoadUserModule rather then SECMOD_AddNewModule. The latter would write //the location of the roots module to the profile, which makes FF2 and TB2 use //it instead of there own module. // //When using SYSTEM_MOZILLA then the libnss3.so lib is typically found in ///usr/lib. This folder may, however, NOT contain the roots certificate //module. That is, just providing the library name in SECMOD_LoadUserModule or //SECMOD_AddNewModule will FAIL to load the mozilla unless the LD_LIBRARY_PATH //contains an FF or TB installation. Additional notes: I am not sure anymore if it really worked with setting the LD_LIBRARY_PATH. If it worked then because a Firefox 2 or Thunderbird 2 profile was used. These profiles contain the path to the root certificate module so that the nss library can load it during initialization. Provided that you can confirm that, one way to fix this would be to provide the complete path to the libnssckbi.so file. This would probably achieved by some kind of configure magic.
$ ls /usr/lib/libnss3.so /usr/lib/libnssckbi.so /usr/lib/libnss3.so /usr/lib/libnssckbi.so we had... #ifdef SYSTEM_MOZILLA if (!SECMOD_HasRootCerts()) SECMOD_AddNewModule("Root Certs", "libnssckbi" SAL_DLLEXTENSION, 0, 0); #endif which I think was basically what this was doing or something similar anyway previously This is definitely broken in the new case as OUString rootModule(RTL_CONSTASCII_USTRINGPARAM("libnssckbi"SAL_DLLEXTENSION)); if (::osl::File::E_None == ::osl::File::getSystemPathFromFileURL(rootModule, rootModulePath)) isn't going to fly. I'll have a look at this when I get a chance, my *guess* is maybe something like the following, depends on how the libs are resolved by nss. I don't want to hardcode "/usr/lib" or "lib" or "lib64" in here.
Created attachment 64413 [details] a guess at this
As I indicated earlier, I do not think that it works to just provide the library name to the SECMOD_LoadUserModule function. To test this you can do the following. -Create a clean Firefox 3 profile. - Use MOZILLA_CERTIFICATE_FOLDER to point to that profile and start OOo -Switch OOo to use OOo file dialogs in the options dialog -Enter a https URL in the file dialog, for example: https://www.sun.com If you build with "debug" then you will get output which tells if the root module could be loaded.
Of course this only works with jl127 / DEV300m57
I just tested the code and changed the line OUString rootModule(RTL_CONSTASCII_USTRINGPARAM("libnssckbi"SAL_DLLEXTENSION)); to OUString rootModule(RTL_CONSTASCII_USTRINGPARAM("libnssckbi"SAL_DLLEXTENSION)); which would be the case in the "SYSTEM_MOZILLA" case. getSystemPathFromFileURL worked. In this case it only returns the same "relative path". In fact the whole code worked. The libnssckbi.so was loaded, probably because it is located in the same folder as libnss3, which is basis/program. And the certificate was verified (there is some neet debug output), when I opened https://www.sun.com. However, on my Linux - box there is a /usr/lib/libnss3.so but there is no libnssckbi3.so next to it. I am not sure if this case can be generally excluded. You certainly know this better. If this is an unlikely case, then the code should work as is and we can close this issue. I suggest that you just run the test with your own build which uses "SYSTEM_MOZILLA". Maybe everything is good after all :)
I meant, of course that I changed the line OUString rootModule(RTL_CONSTASCII_USTRINGPARAM("${OOO_BASE_DIR}/program/libnssckbi"SAL_DLLEXTENSION));
I have /lib/libnss3.so and /lib/libnssckbi.so all the way back to F-9 which is the oldest install I have here locally. Suse reportedly is the same, while debian apparently has... /usr/lib/nss/libnssckbi.so /usr/lib/libssl3.so so I'll give this a go in DEV300_m57 when I get a chance, but looks like its most likely to be problematic on Debian
I suppose you meant libnss3 instead of libssl3. Correct?
jl: yes, mistaken grep and therefore cut'n'waste by me...
I don't think we should release with xmlsecurity broken -> 3.2
Yeah, afaics this "just works" for me, i.e. Thread: 1 :[xmlsecurity] Using profile: /home/caolan/.mozilla/firefox/kqk79ujf.default Thread: 1 :[xmlsecurity] Added new root certificate module "Root Certs for OpenOffice.org" contained in libnssckbi.so i.e. from strace nss goes and searches in the profile dir and digs around ,presumably via dlopen, the ld paths. [pid 5186] open("/home/caolan/.mozilla/firefox/kqk79ujf.default/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/opt/openoffice.org3/program/../basis-link/program/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/opt/openoffice.org3/program/../basis-link/program/../ure-link/lib/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/opt/openoffice.org3/program/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/opt/openoffice.org3/program/../basis-link/program/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/opt/openoffice.org3/program/../basis-link/ure-link/lib/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 5186] open("/usr/lib64/libnssckbi.so", O_RDONLY) = 54 cmc->rene: best to make sure this works on debian as well.
cmc->rene: Works fine for me with-system-mozilla in m61, can you check same in Debian.
Whats the state of this issue? Fixed or still broken? Could the state be changed to fixed/verified or is it needed to promote this as a stopper for OOo 3.2? If yes, please do so on the list or correct the state of the issue. Thx
Any update here? If there isn't any new information until end of this week, I will change the target of this issue to eliminate this issue from the 3.2 list.
As announced I re-target this issue. If there is something to fix, please find a release and set the according target. If there isn't something to fix, please close this issue.
Reset assigne to the default "issues@openoffice.apache.org".