Bug 1720464 - land NSS NSS_3_69_RTM UPGRADE_NSS_RELEASE, r=ckerschb DONTBUILD

2021-08-05  Martin Thomson  <mt@lowentropy.net>

o  	* lib/nss/nss.h, lib/softoken/softkver.h, lib/util/nssutil.h:
|  	Set version numbers to 3.69 final
|  	[2f5c77e2c5b9] [NSS_3_69_RTM] <NSS_3_69_BRANCH>
|
2021-07-30  Martin Thomson  <mt@lowentropy.net>

o  	* .hgtags:
|  	Added tag NSS_3_69_BETA1 for changeset 60211e7f03ee
|  	[51b699171a91] <NSS_3_69_BRANCH>
|
2021-07-29  Martin Thomson  <mt@lowentropy.net>

o  	* lib/ssl/sslsock.c:
|  	Bug 1722613 - Disable DTLS 1.0 and 1.1 by default, r=rrelyea
|
|  	[60211e7f03ee] [NSS_3_69_BETA1]
|
2021-07-15  Robert Relyea  <rrelyea@redhat.com>

o  	* automation/taskcluster/docker-builds/Dockerfile,
~  	automation/taskcluster/docker-gcc-4.4/Dockerfile,
   	automation/taskcluster/docker/Dockerfile, lib/softoken/sftkpwd.c,
   	tests/dbtests/dbtests.sh:
   	Bug 1720226 integrity checks in key4.db not happening on private
   	components with AES_CBC When we added support for AES, we also added
   	support for integrity checks on the encrypted components.

   	It turns out the code that verifies the integrity checks was broken
   	in 2 ways:

   	 1. it wasn't accurately operating when AES was being used (the if
   	statement wasn't actually triggering for AES_CBC because we were
   	looking for AES in the wrong field). 2. password update did not
   	update the integrity checks in the correct location, meaning any
   	database which AES encrypted keys, and which had their password
   	updated will not be able to validate their keys.

   	While we found this in a previous rebase, the patch had not been
   	pushed upstream.

   	 The attached patch needs sqlite3 to run the tests.

   	[1e86f5cfc1cd]

Differential Revision: https://phabricator.services.mozilla.com/D121837

security/nss/TAG-INFO

@@ -1 +1 @@
-e9236397be13
+NSS_3_69_RTM