NSS 3.14 release

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

NSS 3.14 release

Kai Engert-4
The NSS team has released Network Security Services (NSS) 3.14, which is
a minor release with the following new features:

- Support for TLS 1.1 (RFC 4346)
- Experimental support for DTLS 1.0 (RFC 4347) and DTLS-SRTP (RFC 5764)
- Support for AES-CTR, AES-CTS, and AES-GCM
- Support for Keying Material Exporters for TLS (RFC 5705)

In addition to the above new features, the following major changes have
been introduced:

- Support for certificate signatures using the MD5 hash algorithm is now
disabled by default.
- The NSS license has changed to MPL 2.0. Previous releases were
released under a MPL 1.1/GPL 2.0/LGPL  2.1 tri-license. For more
information about MPL 2.0, please see
http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional explantation
on GPL/LGPL compatibility, see security/nss/COPYING in the source code.
- Export and DES cipher suites are disabled by default. Non-ECC AES and
Triple DES cipher suites are enabled by default.

NSS 3.14 source tarballs can be downloaded from
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_14_RTM/src/
The CVS tag is NSS_3_14_RTM.

===============
New in NSS 3.14
===============

The sections that follow discuss specific changes in NSS 3.14 in more
detail.

* Support for TLS 1.1 (RFC 4346) has been added
( https://bugzilla.mozilla.org/show_bug.cgi?id=565047 )

To better support TLS 1.1 and future versions of TLS, a new version
range API was introduced to allow applications to specify the desired
minimum and maximum versions. These functions are intended to replace
the now-deprecated use of the SSL_ENABLE_SSL3 and SSL_ENABLE_TLS socket
options. The following functions have been added to the libssl library
included in NSS 3.14

- SSL_VersionRangeGet (in ssl.h)
- SSL_VersionRangeGetDefault (in ssl.h)
- SSL_VersionRangeGetSupported (in ssl.h)
- SSL_VersionRangeSet (in ssl.h)
- SSL_VersionRangeSetDefault (in ssl.h)

* To better ensure interoperability with peers that support TLS 1.1, NSS
has altered how it handles certain SSL protocol layer events. Such
changes may present interoperability concerns when enabling TLS 1.1.

- When connecting to a server, the record layer version of the initial
ClientHello will be at most { 3, 1 } (TLS 1.0), even when attempting to
negotiate TLS 1.1 ( https://bugzilla.mozilla.org/show_bug.cgi?id=774547
)
- The choice of client_version sent during renegotiations has changed.
See the "Changes" section below.

* Experimental Support for DTLS (RFC 4347) and DTLS-SRTP (RFC 5764)

DTLS client and server support has been added in NSS 3.14. Because the
test coverage and interoperability testing is not yet at the same level
as other NSS code, this feature should be considered "experimental" and
may contain bugs.

The following functions have been added to the libssl library included
in NSS 3.14

- DTLS_ImportFD (in ssl.h)
- DTLS_GetHandshakeTimeout (in ssl.h)
- SSL_GetSRTPCipher (in ssl.h)
- SSL_SetRTPCiphers (in ssl.h)

* Support for AES-GCM

Support for AES-GCM has been added to the NSS PKCS #11 module
(softoken), based upon the draft 7 of PKCS #11 v2.30.

WARNING: Because of ambiguity in the current draft text, applications
should ONLY use GCM in single-part mode (C_Encrypt/C_Decrypt). They
should NOT use multi-part APIs (C_EncryptUpdate/C_DecryptUpdate).

* Support for application-defined certificate chain validation callback
when using libpkix

To better support per-application security policies, a new callback has
been added for applications that use libpkix to verify certificates.
Applications may use this callback to inform libpkix whether or not
candidate certificate chains meet application-specific security
policies, allowing libpkix to continue discovering certificate paths
until it can find a chain that satisfies the policies.

The following types have been added in NSS 3.14

- CERTChainVerifyCallback (in certt.h)
- CERTChainVerifyCallbackFunc (in certt.h)
- cert_pi_chainVerifyCallback, a new option for CERTValParamInType (in
certt.h)
- A new error code: SEC_ERROR_APPLICATION_CALLBACK_ERROR (in secerr.h)

* New for PKCS #11

PKCS #11 mechanisms:

- CKM_AES_CTS
- CKM_AES_CTR
- CKM_AES_GCM (see warnings against using
C_EncryptUpdate/C_DecryptUpdate above)
- CKM_SHA224_KEY_DERIVATION
- CKM_SHA256_KEY_DERIVATION
- CKM_SHA384_KEY_DERIVATION
- CKM_SHA512_KEY_DERIVATION

===================
Changes in NSS 3.14
===================

* Performance enhancements for Intel Macs
( https://bugzilla.mozilla.org/show_bug.cgi?id=333601 )

When building for Intel Macs, NSS will now take advantage of optimized
assembly code for common operations. These changes have the observed
effect of doubling RSA performance.

* New default cipher suites
( https://bugzilla.mozilla.org/show_bug.cgi?id=792681 )

The default cipher suites in NSS 3.14 have been changed to better
reflect the current security landscape. The defaults now better match
the set that most major Web browsers enable by default.

* When performing an SSL renegotiation, the client_version that is sent
in the renegotiation ClientHello will be set to match the client_version
that was sent in the initial ClientHello
( https://bugzilla.mozilla.org/show_bug.cgi?id=783448 ). This is needed
for compatibility with IIS.

* Certificate signatures that make use of the MD5 hash algorithm will
now be rejected by default. Support for MD5 may be manually enabled (but
is discouraged) by setting the environment variable of
"NSS_HASH_ALG_SUPPORT=+MD5" or by using the NSS_SetAlgorithmPolicy
function. Note that SSL cipher suites with "MD5" in their names are NOT
disabled by this change; those cipher suites use HMAC-MD5, not plain
MD5, and are still considered safe.

* Maximum key sizes for RSA and Diffie-Hellman keys have been increased
to 16K bits.

* Command line utilities tstclnt, strsclnt, and selfserv have changed.
The old options to disable SSL 2, SSL 3 and TLS 1.0 have been removed
and replaced with a new -V option that specifies the enabled range  of
protocol versions (see usage output of those tools).

======================
Bugs fixed in NSS 3.14
======================

This Bugzilla query returns all the bugs fixed in NSS 3.14:
https://bugzilla.mozilla.org/buglist.cgi?list_id=4643675;resolution=FIXED;classification=Components;query_format=advanced;product=NSS;target_milestone=3.14


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Julien Pierre-3
Oracle still ships NSS with many products even though we are no longer
actively involved with its development. We do pick up new releases from
time to time. We picked up 3.13.x last year and I'm looking into picking
up 3.14 .

The following changes may be problematic :

1) * New default cipher suites
( https://bugzilla.mozilla.org/show_bug.cgi?id=792681 )

The default cipher suites in NSS 3.14 have been changed to better
reflect the current security landscape. The defaults now better match
the set that most major Web browsers enable by default.


This doesn't just affect browsers. There are other client apps that were
written with the existing defaults in mind.

I could understand if this change was only about removing cipher suites
that have had vulnerabilities removed from the default list. But this
not the case, and some ciphers were also added.
It would appear to be a binary compatibility problem. Some applications
may not behave as intended without both a source change and
recompilation, ie. some ciphers will be enabled when they are not
expected to be.
This change will break one of the test suites we have with our web
server and traffic director applications, in particular.

If this change was done in order to save a few lines of code in the
browser at the cost of breaking existing applications, it doesn't seem
like a good tradeoff.
In the past, binary compatibility was always maintained for minor NSS
releases. Was it the deliberate intent of NSS 3.14 to break binary
compatibility ?

2)
- The NSS license has changed to MPL 2.0. Previous releases were
released under a MPL 1.1/GPL 2.0/LGPL  2.1 tri-license. For more
information about MPL 2.0, please see
http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional explantation
on GPL/LGPL compatibility, see security/nss/COPYING in the source code.


This may be a serious problem also, but IANAL, so that is not for me to
decide.

3)* Support for TLS 1.1 (RFC 4346) has been added
( https://bugzilla.mozilla.org/show_bug.cgi?id=565047 )

To better support TLS 1.1 and future versions of TLS, a new version
range API was introduced to allow applications to specify the desired
minimum and maximum versions. These functions are intended to replace
the now-deprecated use of the SSL_ENABLE_SSL3 and SSL_ENABLE_TLS socket
options.

Q: will unmodified applications that use the deprecated interfaces still continue to work identically ? This appears to be the case from reading the above bug, but I want to make sure that is correct.

4) SSL PKCS#11 bypass is now conditionally built.
https://bugzilla.mozilla.org/show_bug.cgi?id=745281

I understand that nobody but Oracle is using bypass at this time. I
appreciate the efforts not to delete the code altogether.
I would like to know if the bypass feature got tested when the patch was
created, and whether it will still be getting tested at all going
forward other than at Oracle.


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Wolfgang Rosenauer-2
In reply to this post by Kai Engert-4
Hi,

I'm trying to provide that version as an RPM package and also run the
testsuite within the build process.

With that version the testsuite fails:

[ 1202s] chains.sh: #2294: Test that OCSP server is reachable - FAILED
[ 1202s] chains.sh: #4023: Test that OCSP server is reachable - FAILED
[ 1202s] chains.sh: #6393: Test that OCSP server is reachable - FAILED

Is it trying to reach an external server here? That wouldn't work in
that build environment. Is there a way to change that?

I already have
export BUILD_OPT=1
export HOST="localhost"
export DOMSUF=" "
export USE_IP=TRUE
export IP_ADDRESS="127.0.0.1"
in my environment.


Thanks,
 Wolfgang
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Kai Engert-4
On Thu, 2012-10-25 at 15:36 +0200, Wolfgang Rosenauer wrote:

> With that version the testsuite fails:
>
> [ 1202s] chains.sh: #2294: Test that OCSP server is reachable - FAILED
> [ 1202s] chains.sh: #4023: Test that OCSP server is reachable - FAILED
> [ 1202s] chains.sh: #6393: Test that OCSP server is reachable - FAILED
>
> Is it trying to reach an external server here?

Yes. Because NSS doesn't contain OCSP server code yet, the test suite
currently depends on contacting an external server (running on host
kuix.de).

> That wouldn't work in
> that build environment. Is there a way to change that?

Not right now. You'll have to disable the test, or ignore those failures
in your restricted environment.

Removing that dependency will require contributions to
https://bugzilla.mozilla.org/show_bug.cgi?id=663733

Regards
Kai


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Wan-Teh Chang-3
In reply to this post by Julien Pierre-3
On Wed, Oct 24, 2012 at 10:19 PM, Julien Pierre
<[hidden email]> wrote:

>
> The following changes may be problematic :
>
> 1) * New default cipher suites
>
> ( https://bugzilla.mozilla.org/show_bug.cgi?id=792681 )
>
> The default cipher suites in NSS 3.14 have been changed to better
> reflect the current security landscape. The defaults now better match
> the set that most major Web browsers enable by default.
>
> This doesn't just affect browsers. There are other client apps that were
> written with the existing defaults in mind.

Any client apps that care about the exact cipher suites enabled need
to enable and disable each cipher suite explicitly. This Chromium code
in this file can be used as code example:

http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/nss_ssl_util.cc?revision=151846&view=markup

Search for "Explicitly enable exactly those ciphers with keys of at
least 80 bits" in that page. You can use different criteria
appropriate for the client app.

> I could understand if this change was only about removing cipher suites that
> have had vulnerabilities removed from the default list. But this not the
> case, and some ciphers were also added.
> It would appear to be a binary compatibility problem. Some applications may
> not behave as intended without both a source change and recompilation, ie.
> some ciphers will be enabled when they are not expected to be.
> This change will break one of the test suites we have with our web server
> and traffic director applications, in particular.
>
> If this change was done in order to save a few lines of code in the browser
> at the cost of breaking existing applications, it doesn't seem like a good
> tradeoff.
> In the past, binary compatibility was always maintained for minor NSS
> releases. Was it the deliberate intent of NSS 3.14 to break binary
> compatibility ?

You need to change your tests to explicitly enable the desired cipher
suites and disable the undesired cipher suites, and not depend on the
defaults. Sorry about the inconvenience.

In year 2012, AES cipher suites, rather than (single) DES cipher
suites, should be enabled by default. We decided to break this
compatibility to improve security. This is also why we disabled SSL
2.0 by default in NSS 3.13
(https://bugzilla.mozilla.org/show_bug.cgi?id=593080). Note that we
waited another two years to change the cipher suite defaults. I think
this is already very conservative.

> 3)* Support for TLS 1.1 (RFC 4346) has been added
>
> ( https://bugzilla.mozilla.org/show_bug.cgi?id=565047 )
>
> To better support TLS 1.1 and future versions of TLS, a new version
> range API was introduced to allow applications to specify the desired
> minimum and maximum versions. These functions are intended to replace
> the now-deprecated use of the SSL_ENABLE_SSL3 and SSL_ENABLE_TLS socket
> options.
>
> Q: will unmodified applications that use the deprecated interfaces still
> continue to work identically ? This appears to be the case from reading the
> above bug, but I want to make sure that is correct.

Yes, I confirm that.

> 4) SSL PKCS#11 bypass is now conditionally built.
> https://bugzilla.mozilla.org/show_bug.cgi?id=745281
>
> ...
> I would like to know if the bypass feature got tested when the patch was
> created, and whether it will still be getting tested at all going forward
> other than at Oracle.

Yes. The default NSS build still compiles the SSL PKCS#11 bypass code.

Wan-Teh
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Chris Newman-6
In reply to this post by Julien Pierre-3
--On October 24, 2012 22:19:40 -0700 Julien Pierre
<[hidden email]> wrote:
>> 2)
>> - The NSS license has changed to MPL 2.0. Previous releases were
>> released under a MPL 1.1/GPL 2.0/LGPL  2.1 tri-license. For more
>> information about MPL 2.0, please see
>> http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional explantation
>> on GPL/LGPL compatibility, see security/nss/COPYING in the source code.
>
> This may be a serious problem also, but IANAL, so that is not for me to
> decide.

Will vulnerability fixes can be provided on the NSS 3.13.x patch train? And
if so, is there a date when vulnerability fixes will no longer be provided
for that version?

                - Chris

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Julien Pierre-3
Chris,

On 10/25/2012 16:18, Chris Newman wrote:
>
> Will vulnerability fixes can be provided on the NSS 3.13.x patch
> train? And if so, is there a date when vulnerability fixes will no
> longer be provided for that version?
>
>         - Chris
>
As I'm no longer a developer on NSS, I will let others answer that question.

Julien

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Julien Pierre-3
In reply to this post by Wan-Teh Chang-3
Wan-Teh,

Thanks for your response, comments inline.

On 10/25/2012 11:17, Wan-Teh Chang wrote:
>
> Any client apps that care about the exact cipher suites enabled need
> to enable and disable each cipher suite explicitly. This Chromium code
> in this file can be used as code example:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/nss_ssl_util.cc?revision=151846&view=markup
I know what code changes are necessary. I'm only a developer on a couple
of NSS applications at this point, not an NSS maintainer.
If this was only about those couple of apps, it wouldn't be an issue.
But there are other apps in Oracle that could be affected.
I can safely say that tracking and modifying every single app that this
binary compatibility change may affect is not going to happen at Oracle
at this point.
Many other apps may not have the same kind of tests we have for ciphers
and won't even catch the issue.
As NSS gets distributed as patches to many existing application, binary
compatibility is a requirement.
> In year 2012, AES cipher suites, rather than (single) DES cipher
> suites, should be enabled by default. We decided to break this
> compatibility to improve security.
I agree that they should be, but the decision of the defaults was always
up to the application until now.

> This is also why we disabled SSL 2.0 by default in NSS 3.13
> (https://bugzilla.mozilla.org/show_bug.cgi?id=593080).
SSL 2.0 has been broken for some time, and nobody can argue with
changing that default, certainly not me.
But adding new ciphers to the default list is a different kind of
change. Unless the DES ciphers were broken, I don't see the rationale
for this change.

> Q: will unmodified applications that use the deprecated interfaces still
> continue to work identically ? This appears to be the case from reading the
> above bug, but I want to make sure that is correct.
> Yes, I confirm that.
Thanks !
>
>> 4) SSL PKCS#11 bypass is now conditionally built.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=745281
>>
>> ...
>> I would like to know if the bypass feature got tested when the patch was
>> created, and whether it will still be getting tested at all going forward
>> other than at Oracle.
> Yes. The default NSS build still compiles the SSL PKCS#11 bypass code.
Great !
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Brian Smith-31
In reply to this post by Chris Newman-6
[hidden email]> wrote:
> Oracle still ships NSS with many products even though we are no
> longer actively involved with its development.

It is important to have somebody at least monitoring the bugs filed/fixed in the NSS component in bugzilla. See https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch for how you can subscribe to a feed of all NSS bug discussions.

Chris Newman wrote:

> --On October 24, 2012 22:19:40 -0700 Julien Pierre
> <[hidden email]> wrote:
> > Oracle still ships NSS with many products even though we are no
> > longer actively involved with its development. We do pick up new
> > releases from time to time. We picked up 3.13.x last year and I'm
> > looking into picking up 3.14 .
> >> 2)
> >> - The NSS license has changed to MPL 2.0. Previous releases were
> >> released under a MPL 1.1/GPL 2.0/LGPL  2.1 tri-license. For more
> >> information about MPL 2.0, please see
> >> http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional
> >> explantation
> >> on GPL/LGPL compatibility, see security/nss/COPYING in the source
> >> code.
> >
> > This may be a serious problem also, but IANAL, so that is not for
> > me to decide.
>
> Will vulnerability fixes can be provided on the NSS 3.13.x patch
> train? And if so, is there a date when vulnerability fixes will no
> longer be provided for that version?

First, I think pretty much everybody agrees that, concerns about backward compatibility aside, the changes that were made were all positive. And, so, we have to balance backward compatibility with old versions of NSS with compatibility with websites on the internet and compatibility with web browsers. Now, there are no people actively contributing to NSS that are arguing in favor of absolute backward compatibility.

AFAICT, there is no plan to work on 3.13.x any more. IMO, it is better to continue to focus development on the trunk.

Even if somebody were to backport fixes to 3.13.x, then that work would also be under the MPL 2.0, for various reasons that, at this point, I think we cannot do anything about. For example, all the fixes in the new version are assumed to have been contributed under MPL 2.0. See the MPL 2.0 FAQ that contains the email address to send licensing questions to: http://www.mozilla.org/MPL/2.0/FAQ.html

Also, I thought the goal was/is to remove the bypass mode code soon. Perhaps that decision will partly be based on how much it gets in the way of the TLS 1.2 implementation? I would be surprised if we required the TLS 1.2 implementation to support the bypass mode.

By the way, I think it would be very useful to know what causes the difference in performance between the bypass mode and the non-bypass mode, to see if we can optimize the non-bypass mode so that everybody (including users of NSS outside of libssl) can get the performance improvements.

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Brian Smith-31
In reply to this post by Julien Pierre-3
Julien Pierre wrote:

> I know what code changes are necessary. I'm only a developer on a
> couple of NSS applications at this point, not an NSS maintainer.
> If this was only about those couple of apps, it wouldn't be an issue.
> But there are other apps in Oracle that could be affected.
> I can safely say that tracking and modifying every single app that
> this binary compatibility change may affect is not going to happen at
> Oracle at this point. Many other apps may not have the same kind of
> tests we have for ciphers and won't even catch the issue. As NSS gets
> distributed as patches to many existing application, binary
> compatibility is a requirement.

Generally everybody is trying to maintain binary compatibility by default. But, there are other concerns too, such as compatibility with other implementations, and/or cost of maintenance issues, that may sometimes outweigh any binary compatibility requirement.

Regarding the cipher suite changes, I think that overall, more applications will benefit than will be hurt. In fact, although it is probably the case that some Oracle products are "affected," it isn't clear from your message whether the effect is negative or positive.

> I agree that they should be, but the decision of the defaults was
> always up to the application until now.

When an application does not explicitly set the set of enabled cipher suites, and/or it doesn't set a particular SSL option, then IMO it is saying "Let the NSS library decide what is best for me." If that isn't a good policy for an application, then it should set the options explicitly.

> Unless the DES ciphers were broken, I don't see the rationale
> for this change.

These were the not the 3DES ciphers; they were the original, weak, DES ciphers. In 2012 it is not worth analyzing whether DES ciphers are strong enough to keep enabled, because it is clear that they are obsolete, and everybody recommends against their use. But, also, see:
http://en.wikipedia.org/wiki/Data_Encryption_Standard#Security_and_cryptanalysis

"In 2008 their COPACOBANA RIVYERA reduced the time to break DES to less than one day, using 128 Spartan-3 5000's."

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS 3.14 release

Chris Newman-6
In reply to this post by Brian Smith-31
--On October 26, 2012 11:52:47 -0700 Brian Smith <[hidden email]> wrote:
> [hidden email]> wrote:
>> Oracle still ships NSS with many products even though we are no
>> longer actively involved with its development.
>
> It is important to have somebody at least monitoring the bugs filed/fixed
> in the NSS component in bugzilla. See
> https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch for how
> you can subscribe to a feed of all NSS bug discussions.

Thanks, I subscribed.

> Chris Newman wrote:
>> Will vulnerability fixes can be provided on the NSS 3.13.x patch
>> train? And if so, is there a date when vulnerability fixes will no
>> longer be provided for that version?
>
> First, I think pretty much everybody agrees that, concerns about backward
> compatibility aside, the changes that were made were all positive.

I consider the license change a big negative at a minimum because it will
cause several engineers to waste time interacting with lawyers. I consider
the technical changes positive to the degree I understand them, including
the compatibility changes (I don't share Julien's concerns on that point).

> And, so, we have to balance backward compatibility with old versions of
NSS

> with compatibility with websites on the internet and compatibility with
> web browsers. Now, there are no people actively contributing to NSS that
> are arguing in favor of absolute backward compatibility.
>
> AFAICT, there is no plan to work on 3.13.x any more. IMO, it is better to
> continue to focus development on the trunk.
>
> Even if somebody were to backport fixes to 3.13.x, then that work would
> also be under the MPL 2.0, for various reasons that, at this point, I
> think we cannot do anything about. For example, all the fixes in the new
> version are assumed to have been contributed under MPL 2.0. See the MPL
> 2.0 FAQ that contains the email address to send licensing questions to:
> http://www.mozilla.org/MPL/2.0/FAQ.html

I can't provide any MPL 2.0 code to customers with problems unless/until my
employer's legal department approves doing so.

                - Chris

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto