On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > On 01/15/2016 12:18 AM, Damjan Jovanovic wrote: > > Hi > > > > I believe we now have enough evidence that a serious issue, #125431, > where > > AOO lies that the password for encrypted files is wrong when it isn't, is > > caused by a failure in NSS: > > * deliberately corrupting the Mozilla profile reproduces the issue on all > > operating systems > > * a patch I've written that reimplements xmlsecurity digest functions > using > > OpenSSL instead of NSS, allows encrypted documents to open despite a > > corrupted Mozilla profile > > * someone with the issue on FreeBSD reported my patch fixes it > > > > Always having been category B and now also commonly breaking in the > field, > > it's past time for NSS to go. But this brings me to my question: what do > we > > replace it with? > > > > We already use OpenSSL for some things, and my patch which uses it is > > enough to fix the problem with opening encrypted files. Its license suits > > us better. Our libxmlsec library can use it in place of NSS. > > Thank you for your work on this. I am certainly in favor of just > using OpenSSL assuming it won't cause backward compatibly issues. > > > > > Java has a rich cryptographic API and is widely used for cryptography. It > > is however an optional dependency to AOO. It also needs the unlimited > > strength JCE policy files to use AES-256, but there are workarounds. > > > > Are there more? > > > > The important differences are: > > * NSS has passed FIPS-140 validation ( > > https://wiki.mozilla.org/FIPS_Validation). OpenSSL hasn't really ( > > https://www.openssl.org/docs/fipsnotes.html) while Java supposedly has ( > > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/FIPS.html > ). > > Do we care? > > * We use certificate verification (for what, digitally signed > documents?). > > This means we need access to the root certificates of all the CAs. > Securely > > updating, expiring and revoking CA certificates across 40 million users > is > > a problem we should rather delegate to someone else. Currently, we are > > using MSCrypto on Windows, and Thunderbird's/Firefox's certificates (via > > NSS) on other platforms. OpenSSL doesn't come with a list of CA > > certificates. Java does, but I don't know whether "This file is > encrypted, > > please install Java to open it" will fly. > > > > Maybe we could combine them. Use OpenSSL for most of xmlsecurity, and > fall > > back to Java when available for its certificates? Or keep NSS but scale > it > > down to only dealing with certificates, and use something else for > > implementing other xmlsecurity features? > > > > Thank you > > Damjan > > > I came to the conclusion NSS was probably chosen for FIPS-140 compliance, the root CA certificates, and the UI in Thunderbird/Firefox for configuring digital certificates system-wide on many platforms, and since it does a lot and no other crypto library really has all those features, it's best to debug and fix our NSS usage for now and consider the other options later. Which I did in r1724971: #i125431# "The Password is incorrect. The file cannot be opened." Fix a serious cross-platform regression caused during SeaMonkey's removal and first released in version 4.1.0, where all features provided by NSS (like opening and saving encrypted documents, digital signatures, etc.) were failing. SYSTEM_MOZILLA doesn't exist any more, yet was being used to check whether to skip loading nssckbi when SECMOD_HasRootCerts() is true, so we were always attempting to load it even when not necessary. Also with SYSTEM_MOZILLA skipping loading it from the system path, we were always trying to load it from "${OOO_BASE_DIR}/program/libnssckbi.so" even when it wasn't there because --with-system-nss was passed to ./configure. This patch fixes the above problems by using SYSTEM_NSS instead of SYSTEM_MOZILLA, which actually exists, now both skipping loading nssckbi when unnecessary, and loading it from the right place when necessary. Now let's release that to our users in 4.2.0 soon? Regards Damjan
