You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Damjan Jovanovic <da...@apache.org> on 2016/01/15 09:18:58 UTC
Remove NSS from xmlsecurity - alternatives?
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.
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
RE: Remove NSS from xmlsecurity - alternatives?
Posted by "Dennis E. Hamilton" <or...@apache.org>.
Great work!
Considering the nature of the issue, where users have important files they can no longer open, I would think getting it into an early maintenance release (e.g., a 4.1.3) along with many other fixes that don't impact UI, localization, documentation, etc., would be a preferable solution.
This does not seem to be the kind of problem to hold back to a feature release.
- Dennis
> -----Original Message-----
> From: Damjan Jovanovic [mailto:damjan@apache.org]
> Sent: Saturday, January 16, 2016 05:26
> To: Apache OO <de...@openoffice.apache.org>
> Subject: Re: Remove NSS from xmlsecurity - alternatives?
>
[ ... ]
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Kay Schenk <ka...@gmail.com>.
On 01/21/2016 04:27 PM, Damjan Jovanovic wrote:
> On Thu, Jan 21, 2016 at 11:53 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>>
>>
>> On 01/21/2016 10:04 AM, Damjan Jovanovic wrote:
>>> On Thu, Jan 21, 2016 at 7:29 PM, Kay Schenk <ka...@gmail.com>
>> wrote:
>>>
>>>>
>>>>
>>>> On 01/16/2016 05:25 AM, Damjan Jovanovic wrote:
>>>>> On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Jan 21, 2016 at 11:53 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On 01/21/2016 10:04 AM, Damjan Jovanovic wrote:
> > On Thu, Jan 21, 2016 at 7:29 PM, Kay Schenk <ka...@gmail.com>
> wrote:
> >
> >>
> >>
> >> On 01/16/2016 05:25 AM, Damjan Jovanovic wrote:
> >>> On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <ka...@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
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Kay Schenk <ka...@gmail.com>.
On 01/21/2016 10:04 AM, Damjan Jovanovic wrote:
> On Thu, Jan 21, 2016 at 7:29 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>>
>>
>> On 01/16/2016 05:25 AM, Damjan Jovanovic wrote:
>>> On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <ka...@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?
>
>>
>> --
>> --------------------------------------------
>> MzK
>>
>>
> Damjan
>
--
--------------------------------------------
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Jan 21, 2016 at 7:29 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On 01/16/2016 05:25 AM, Damjan Jovanovic wrote:
> > On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <ka...@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
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Kay Schenk <ka...@gmail.com>.
On 01/16/2016 05:25 AM, Damjan Jovanovic wrote:
> On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Damjan Jovanovic <da...@apache.org>.
On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk <ka...@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
Re: Remove NSS from xmlsecurity - alternatives?
Posted by Kay Schenk <ka...@gmail.com>.
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
>
--
--------------------------------------------
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org