NSS 3.69 Release

[Martin Thomson]

Network Security Services (NSS) 3.69 was released on 5 August 2021.

The HG tag is NSS_3_69_RTM. NSS 3.69 requires NSPR 4.32 or newer.

NSS 3.69 source distributions are available on ftp.mozilla.org for secure HTTPS download: <https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_69_RTM/src/>

Bugs fixed:

   - Bug 1722613 - Disable DTLS 1.0 and 1.1 by default
   - Bug 1720226 - integrity checks in key4.db not happening on private components with AES_CBC
   - Bug 1720235 - SSL handling of signature algorithms ignores environmental invalid algorithms.
   - Bug 1721476 - sqlite 3.34 changed it's open semantics, causing nss failures.
   - Bug 1720230 - Gtest update changed the gtest reports, losing gtest details in all.sh reports.
   - Bug 1720228 - NSS incorrectly accepting 1536 bit DH primes in FIPS mode
   - Bug 1720232 - SQLite calls could timeout in starvation situations.
   - Bug 1720225 - Coverity/cpp scanner errors found in nss 3.67
   - Bug 1709817 - Import the NSS documentation from MDN in nss/doc.
   - Bug 1720227 - NSS using a tempdir to measure sql performance not active

NSS 3.69 shared libraries are backwards-compatible with all older NSS 3.x shared libraries. A program linked with older NSS 3.x shared libraries will work with NSS 3.69 shared libraries without recompiling or relinking. Furthermore, applications that restrict their use of NSS APIs to the functions listed in NSS Public Functions will remain compatible with future versions of the NSS shared libraries.

Bugs discovered should be reported by filing a bug report at <https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS>

Release notes will be available at <https://firefox-source-docs.mozilla.org/security/nss/releases/nss_3_69.html> though you should expect some delay.

[Robert Relyea]

On 8/8/21 10:12 PM, Martin Thomson wrote:
> Network Security Services (NSS) 3.69 was released on 5 August 2021.
>
> The HG tag is NSS_3_69_RTM. NSS 3.69 requires NSPR 4.32 or newer.

Hey, was there a bump in the version requirements on NSS for ESR? This
is a serious problem for us. It takes us a month or so go get new
versions of NSS through our release process, so we need that runway
before we can pick up a new version of NSS. Dumping new requirements of
ESR makes it impossible for us to really plan that landing, as well as
makes it impossible to meet our new ESR release requirements before the
old ESR runs out.

Do you know what requirements forced the bump. Can we get dispensation
to release with the older version of NSS. Also I'm not seeing a release
announcement for NSS 3.68, so there's no record of what the changes were.

Please, in the future, do not pick up new version of NSS into ESR once
the schedule is made. It's better for us to pick up individual fixes
than rebase to a new version, and if you need to, please give us lots of
warning.

Thanks,


bob

[Martin Thomson]

I don't know.  This was the same NSPR version used in the last version of NSS.

The release notes are in the tree:

https://searchfox.org/nss/source/doc/rst/releases

The bump was in 3.68 according to those.

--
You received this message because you are subscribed to the Google Groups "dev-tec...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-cryp...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/bfb7696a-c4df-bcb0-bce6-3f4049541c00%40redhat.com.

[Kai Engert]

Hello Bob,

you didn't say which ESR version your report is about. Is it about the
old ESR 78, or the new ESR 91?

It seems old ESR 78 didn't have any changes recently.

The most recent changes to new ESR 91 were:

- use NSS 3.68 on 2021-07-13

https://hg.mozilla.org/releases/mozilla-esr91/log/tip/security/nss/TAG-INFO

- use of NSPR 4.32 on 2021-07-13
https://hg.mozilla.org/releases/mozilla-esr91/log/tip/nsprpub/TAG-INFO

I don't see any changes to NSPR/NSS in ESR 91 after it was released.

The above changes were done prior to the ESR 91 beta date.

Can you please clarify which of the above changes was problematic for
you, and why?

Furthermore, you are responding to an email about the NSS 3.69 release.
ESR 91 doesn't use that, it's on NSS 3.68.

https://kuix.de/mozilla/versions/

Kai

[Robert Relyea]

On 8/20/21 1:44 AM, Kai Engert wrote:
> Hello Bob,
>
> you didn't say which ESR version your report is about. Is it about the
> old ESR 78, or the new ESR 91?
>
> It seems old ESR 78 didn't have any changes recently.
>
> The most recent changes to new ESR 91 were:
>
> - use NSS 3.68 on 2021-07-13
>
> https://hg.mozilla.org/releases/mozilla-esr91/log/tip/security/nss/TAG-INFO
>
>
> - use of NSPR 4.32 on 2021-07-13
> https://hg.mozilla.org/releases/mozilla-esr91/log/tip/nsprpub/TAG-INFO
>
> I don't see any changes to NSPR/NSS in ESR 91 after it was released.

I was 91. There wasn't an announcement on this list. I picked up 3.67 on
June 17, and completed the resulting builds on July 6. This change was
made 1 week after I was developement complete for the NSS portion of our
Rebase. QA for all our platforms are finishing this week (completed last
week for RHEL 9/RHEL 8). Changing base requirements for Firefox ESR this
late means we can only fail to meet any ESR schedules. As you know it
take time to pick up rebases, as well as meet all our internal
deadlines. July 13 is way too late for us to handle this kind of change
to ESR.

There are a lot of more reasons why it's extremely expensive for us to
move to NSS 3.68 on RHEL. What I need now is permission to ship our ESR
with NSS 3.67 (frankly I'm hosed if I don't get that).

NSPR 4.32 may be less of an issue, but I'll need to know this week and
many decisions makers or on PTO.

>
> The above changes were done prior to the ESR 91 beta date.
>
> Can you please clarify which of the above changes was problematic for
> you, and why?

Moving ESR 91 to NSS 3.68 is highly problematic for us. In the future
I'd like to be in any of those discussions, particularly. ESR is a big
deal and big cost, we can't take last minute major revision bumps,
particularly in NSS.

>
> Furthermore, you are responding to an email about the NSS 3.69
> release. ESR 91 doesn't use that, it's on NSS 3.68.

yes, it was just a convenience. This has nothing to do with NSS 3.69,
other than the fact we never actually announced NSS 3.68 on this list
(which makes it even more problematic that we make it a requirement for
ESR 91.


bob

[Benjamin Beurdouche]

Hi all,

Interesting, I had no knowledge of those specific needs for RedHat. I’ll document that in the release management page so that it doesn’t happen in the future.

Bob, would it be useful if I released a 3.68.1 version reverting the NSPR requirements to 4.30 early next week ?

Kai, if the solution above could be useful for Bob, my understanding is that it would be ok for NSS 3.68.1 and the future dot releases for ESR to remain on NSPR 4.30 since we don’t use the changes within NSS. Firefox could keep using 4.32. Is that correct?

About the release notes of 3.68, looks like I just forgot, sorry about that.

B.

> On Aug 20, 2021, at 7:36 PM, Robert Relyea <rre...@redhat.com> wrote:

> --
> You received this message because you are subscribed to the Google Groups "dev-tec...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-cryp...@mozilla.org.

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/3ba8b72c-2520-5845-63ab-4c3c7d27b85a%40redhat.com.

[Robert Relyea]

On 8/20/21 1:47 PM, Benjamin Beurdouche wrote:
> Hi all,
>
> Interesting, I had no knowledge of those specific needs for RedHat. I’ll document that in the release management page so that it doesn’t happen in the future.

Yes, ESR is quite a dance for us. We need to update our ca-certificates,
nss, and nspr before ESR xxx releases so that we are ready for the
firefox team to pick it up. Typically we release on 5-6 old versions of
RHEL that are still under support, so we not only have to build, but
also QA those releases, so any changes later than 3 months before an ESR
release can cause us some real issues.

>
> Bob, would it be useful if I released a 3.68.1 version reverting the NSPR requirements to 4.30 early next week ?

No, NSPR 4.32 is not really a problem. It's a pain, but I think we can
respin NSPR rather quickly. What I need is permission to ship our ESR
with NSS 3.67.

>
> Kai, if the solution above could be useful for Bob, my understanding is that it would be ok for NSS 3.68.1 and the future dot releases for ESR to remain on NSPR 4.30 since we don’t use the changes within NSS. Firefox could keep using 4.32. Is that correct?
>
> About the release notes of 3.68, looks like I just forgot, sorry about that.

So in alll honesty, I knew when 3.68 released (since I saw the tag),
what I didn't know was that ESR depended on it (which would have set off
alarm bells much earlier). Also once I found out, there wasn't any
release notes to tell me what actually changes.

I did look at the list of actual patches to NSS 3.68, and I only saw one
patch that would have any affect on our Firefox version (an ECH patch). 
Everything else will have zero impact on Firefox, which is why I think
it should be OK to let us ship with NSS 3.67. I believe the desire was
to pick up NSPR 4.32 into Firefox and that triggered the more expansive
picking up on NSS 3.68. (I'm hoping that's the case).


bob

[Kai Engert]

Bob,

FYI, the usual deadline for the NSS version of ESR is 4 weeks prior to
the release of a new ESR, which is the time ESR goes into beta.

Kai

[Robert Relyea]

The agreement we've had is that is 2 release prior. The biggest issue is
a major change like this was not announced on this list and all the
stake holders were not brought in.

But that is currently water under the bridge. I'm in a real pickle
because of this, and I'm just looking for approval to ship our ESR with
the old NSS. At this point it's really can I ship it with the old NSS,
or do I have to wait 8 months to ship ESR. I really don't have any other
choice (our FIPS plan is such that I can no longer change NSS version
until 2022).

My proposed plan going forward is to pick up NSPR 4.32, leave NSS 3.67
(patch our ESR to accept 3.69) and backport any security patches to NSS
3.68.x into our NSS 3.67 and resync at the next ESR.

What I need is is this an acceptible plan for mozilla, or will we be in
trouble for this.

bob

>
> Kai
>

[Martin Thomson]

Bug 1717610 is a risk here; it might be that the ESR code depends on that function being present.  But if you want to backport it, I don't see a problem.

--
You received this message because you are subscribed to the Google Groups "dev-tec...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-cryp...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/7854a2f4-f735-cb4b-0285-f95a81c43248%40redhat.com.

[Robert Relyea]

On 8/23/21 4:21 PM, Martin Thomson wrote:

Bug 1717610 is a risk here; it might be that the ESR code depends on that function being present.  But if you want to backport it, I don't see a problem.

Actually that's not an issue because we don't ship that code in our NSS release since it's never been integrated into the NSS builds;). Our Firefox team must have their own copy.

At some point we should make it a issue.... I'd really love to loose libpkix;).

bob