On 01/21/2016 04:27 PM, Damjan Jovanovic wrote:
> On Thu, Jan 21, 2016 at 11:53 PM, Kay Schenk <kay.sch...@gmail.com> wrote:
>
>>
>>
>> On 01/21/2016 10:04 AM, Damjan Jovanovic wrote:
>>> 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?
>>>
>>
>> Ok, now I'm a bit confused...your previous comment
>>
>> "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."
>>
>> Shouldn't we just remove all references to NSS?
>>
>>
> I later said "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." On #125431 comment 76 I elaborated further:
>
> --snip--
> 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.
> --snip--
>
> Damjan
>
ah...OK. I did not stay current on this issue. Thanks for the follow-up.
--
--------------------------------------------
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
