On Thu, Jan 21, 2016 at 7:29 PM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > > On 01/16/2016 05:25 AM, Damjan Jovanovic wrote: > > 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 > > So, should we also remove the "mozilla-build" references/logic from > main/configure.ac and main/configure? > > >From briefly reading configure.ac, it seems we need mozilla-build on Windows to build NSS when --with-system-nss isn't in use. What does need removing, is the SYSTEM_MOZILLA define still used in a few places (see OpenGrok), but it's not clear what to do in those places: replace it with SYSTEM_NSS, or remove it completely? > > -- > -------------------------------------------- > MzK > > Damjan
