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?
--
--------------------------------------------
MzK
"Though no one can go back and make a brand new start,
anyone can start from now and make a brand new ending."
-- Carl Bard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
