Uprev NSS to 3.18 RTM

README.chromium

Index: README.chromium
diff --git a/README.chromium b/README.chromium
index fc13a903e5bdb8e1779fbc6151d1c2344539cde7..d0a9070eaab025d56570886c45c5f6e5b736d773 100644
--- a/README.chromium
+++ b/README.chromium
@@ -7,7 +7,7 @@ License File: nss/COPYING
 Security Critical: yes
 
 Description:
-NSS 3.16.5 with NSPR 4.10.7
+NSS 3.18 with NSPR 4.10.7
 
 This copy of NSS has been customized for Chromium.  NSPR is also put here
 rather than in a separate directory to emphasize the fact that Chromium is
@@ -21,7 +21,7 @@ Linux.
 
 The source code was checked out from the mozilla.org CVS or hg repository using
 the nspr-checkout.sh and nss-checkout.sh scripts in the scripts directory.
-The current source code was checked out with the hg tag NSS_3_16_5_RTM
+The current source code was checked out with the hg tag NSS_3_18_RTM
 and the hg tag NSPR_4_10_8_RTM.
 
 Local Modifications:
@@ -45,10 +45,6 @@ We made the following local changes to NSPR.
   DO NOT upstream this patch.
 
 We made the following local changes to NSS.
-- patches/nss-static.patch: to build NSS as static libraries and omit
-  libpkix (the new certification path validation library) and
-  softoken/legacydb (support for the old Berkeley DB databases).  See NSS
-  bug 534471 (https://bugzilla.mozilla.org/show_bug.cgi?id=534471).
 - nss/exports_win.def: The list of exports to use when building nss as a
   dynamic library (crnss.dll).
 - nss/lib/ckfw/builtins/certdata.c: a generated file. Do an upstream NSS
@@ -69,3 +65,7 @@ We made the following local changes to NSS.
 - patches/nss-chacha20-poly1305.patch: Support ChaCha20+Poly1305 cipher
   suites.  See NSS bug 917571
   (https://bugzilla.mozilla.org/show_bug.cgi?id=917571).
+- patches/nss-static.patch: to build NSS as static libraries and omit

[wtc, 2015/03/20 00:09:46]

I guess you moved this patch here so that all the patches are listed together.
If so, I suggest we list this patch first, before nss-remove-fortezza.patch,
because this is the biggest/most permanent (in the sense that it is most
difficult to upstream) one among the patches.

[Ryan Sleevi, 2015/03/20 00:15:36]

No, because I forgot to apply it first when merging all the bits. It also made
it easier to track the changes, by merging the small bits first, resolving the
conflicts, and then the larger change.

As you note, because this one is the most likely to create conflicts, any
further conflicts will propagate to the rest of the patches; applying this last
reduces the diff hunk fuzzing of the earlier patches.

+  libpkix (the new certification path validation library) and
+  softoken/legacydb (support for the old Berkeley DB databases).  See NSS
+  bug 534471 (https://bugzilla.mozilla.org/show_bug.cgi?id=534471).