https://bz.apache.org/ooo/show_bug.cgi?id=125431
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Latest|--- |4.2.0-dev Confirmation in| | OS|Mac OS X 10.9 |All Product|Calc |General Target Milestone|--- |4.2.0 Hardware|Mac |All Component|open-import |code Severity|Critical |Major --- Comment #76 from [email protected] --- (In reply to Arrigo Marchiori from comment #75) > Created attachment 85251 [details] > Log from a (supposedly) debug build showing an exception ``bubbling up'' > > This log file was produced in the ~/.openoffice.org/4/user/temp directory by > a (supposedly) debug-enabled build of AOO 4.1.2 under FreeBSD. > > I cannot remember if it logs a failed open or save attempt... > Please tell me if I shall provide other information like this, and how. Your log looks like a save attempt but it's not very revealing. No useful responses to my email have been received yet, so I'm not sure what direction to take to fix this. I think NSS was chosen over alternatives due to (1) the fact it is FIPS 140 certified, (2) it provides root CA certificates we use for validating digital signatures, and (3) it provides management of personal digital certificates via the settings in Firefox/Thunderbird, so you can set them up once there, and have them work across all applications on your system. On Windows, AOO will use Microsoft's MS Crypto API for (2) and (3) instead, but other platforms don't have something like that, so Mozilla is used as the next best thing. Thus I am not sure replacing NSS is a viable option any more. OpenSSL doesn't provide its own root CA certificates, nor any GUI for managing certificates, nor a system wide database of personal digital certificates. Java has its own root CA certificates, but I don't think there's a system-wide personal digital certificate store, nor a GUI for managing anything; Java is also optional to AOO. We are left with either replacing the other cryptographic functions of NSS with alternatives while leaving it for use in digital signatures (so when it breaks you can't sign or verify digital signatures, but you can hash and encrypt/decrypt), possibly losing FIPS 140 validity in the process (unless Java is used, which seems to have been FIPS 140 certified, but I don't know whether "This document is encrypted, please install Java to open it" will fly), or fixing NSS. Let's try and fix NSS first. There's a BASIC macro that detects Mozilla profiles and prints out settings on https://wiki.openoffice.org/wiki/Certificate_Detection. On FreeBSD where I can reproduce your problem, it detects my Firefox profile, then gives an error about creating a SHA-256 digest, and then claims the right password is wrong. In the code, the method ONSSInitializer::getCipherContext() in main/xmlsecurity/source/xmlsec/nss/nssinitializer.cxx calls initNSS() which fails. Why? initNSS() calls InitNSSInitialize(), then its operator(), which calls nsscrypto_initialize() which returns false (a failure) for bInitialized, yet true for bNSSInit. nsscrypto_initialize() is a complicated function, but it calls xmlsec_trace() to log errors, which needs a debug build and the environment variable XMLSECURITY_TRACE=1, with which I get: [xmlsecurity] Using profile: /path/to/CORRUPT/PROFILE [xmlsecurity] FAILED to load the new root certificate module "Root Certs for Apache OpenOffice" contained in /AOO/main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/../program/libnssckbi.so Adding fprintf(stderr, "...\n"); statements all over the show and tracing execution through the complicated nsscrypto_initialize() function critical to this bug, led me to see how: * The SYSTEM_MOZILLA define doesn't exist; it hasn't existed since SeaMonkey's removal in AOO 4.1.0. But because the "if (!SECMOD_HasRootCerts())" section is inside a "#if defined SYSTEM_MOZILLA", it is skipped, and loading of libnssckbi is always attempted, even when it's unnecessary because we already have the root certificates. * The path to libnssckbi is: - "nssckbik" + SAL_DLLEXTENSION on OS/2 - "libnssckbi" + SAL_DLLEXTENSION with SYSTEM_MOZILLA defined (ie. never) - "${OOO_BASE_DIR}/program/libnssckbi" + SAL_DLLEXTENSION otherwise which means, on non-OS/2 platforms, ***ONLY*** when we're using the ***INTERNAL*** NSS library (causing NSS and its libraries to build and ship with AOO in opeonoffice4/program) can NSS initialize! Using the system NSS causes AOO to still look for libnssckbi.so in its own openoffice4/program directory, where it won't find it!!! Let me build AOO with and without its internal NSS to confirm, and then work out patches for the above issues. -- You are receiving this mail because: You are the assignee for the issue.
