Rebase RHEL 5.11.z to NSS 3.21 in preparation for Firefox 45.
Karel asked for a list of changes in the newer NSS, here's a summary: Previously, we used NSS 3.19.x. The relevant changes that were added in version until 3.21 are: - CA certificates (list was updated twice, in 3.19.3 and 3.21) - Added support for DHE server side ciphersuites, disabled by default. (This was already included in RHEL 7 with local patches.) - disabled support for very old C compilers (pre C89) - support TLS extended master secret extension (RFC 7627), off by default - several other new APIs (that new application code could use) - upstream changed to build with ECC enabled by default - stricter build options, that cause most warnings to be treated as errors More details here: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.3_release_notes https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.20_release_notes https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.21_release_notes
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Please see bug 1297888 comment 4 (attachment 1116177 [details]), which is the patch to keep the legacy CA certificates enabled. It should apply cleanly on top of NSS 3.21
(In reply to Kai Engert (:kaie) from comment #1) > - support TLS extended master secret extension (RFC 7627), off by default We cannot support this feature because of the older softokn that we're shipping with RHEL. We will force this feature to remain disabled.
Created attachment 1128523 [details] nss-prevent-abi-issue.patch Elio, please apply this patch from Bob, as a workaround to the issue that Hubert had identified.
Created attachment 1128552 [details] nss-prevent-abi-issue.patch fixed patch
Created attachment 1128909 [details] all changes for rebase - in patch format - preliminary This a first cut of a work in progress. We need the rebase to nspr-4.11.0 ack'ed and in the buildroot override to properly build in brew. I'm investigating the best way to deal with having an older gcc on rhel-5 and discuss it with Kai and Bob. More details later.
Created attachment 1129926 [details] all changes for rebase - in patch format modified: .gitignore modified: sources modified: 1129573-certutil-key-size-reversed.patch modified: iquote4nss.patch modified: nss.spec modified: ssl-server-min-key-sizes.patch renamed: nss-ca-2.4-enable-legacy.patch -> nss-ca-2.6-enable-legacy.patch new file: no_compiler_tag.patch - will offer details later new file: nss-prevent-abi-issue.patch - the one provided by Kai new file: nss-tests-prevent-abi-issue.patch - complements previous one deleted: nss-3.20.1-security-fix.patch - obsoleted by 3.21 rebase scratch build with these changes applied can be found at https://brewweb.devel.redhat.com/taskinfo?taskID=10547348 since nspr-4.11.0 is not yet available I had to use nspr-4.0.8.
Created attachment 1134645 [details] all changes for rebase - in patch format I was able to do scratch build with this changes applied. Saving this new version of work in progress in case we do need to rebase once ongoing consultation helps decide.
Created attachment 1141835 [details] add 3 missing compatibility patches --in patch format
Elio, the patches to keep some cipher suites disabled change a different number of cipher suites on rhel 5 (8x) vs. rhel 6 (6x) Is this intentional?
(In reply to Kai Engert (:kaie) from comment #22) > Elio, the patches to keep some cipher suites disabled change a different > number of cipher suites on rhel 5 (8x) vs. rhel 6 (6x) Is this intentional? Yes it is. I created the patch keep some cipher suites disabled ny comparing the current rhel-5.11.z sources against those for the last release for 5 that nss-3.19.1-4.el5_11. On rhel-6.7.z the order of the cipher suites is diffrent than on rhel-5.11.z but the wnabing and disabling of ciper suites by default should be the same. I verified this as follows: (I have all nss branches checked out on my development system). For 6 find out what's enabled by default grep "SSL_ALLOWED, PR_TRUE, " ../rhel-6.7/nss-3.21.0/nss/lib/ssl/ssl3con.c > rhel-6.7.z-enabled.txt cat rhel-6.7.z-enabled.txt { TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_128_GCM_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_256_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_256_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_128_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_128_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_RC4_128_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_RC4_128_MD5, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, if (config_match(suite, SSL_ALLOWED, PR_TRUE, &ss->vrange, ss)) { For 5 do likewise grep "SSL_ALLOWED, PR_TRUE, " ./nss-3.21.0/nss/lib/ssl/ssl3con.c > rhel-5.11.z-enabled.txt cat rhel-5.11.z-enabled.txt { TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_128_GCM_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_128_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_128_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_256_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_AES_256_CBC_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_RC4_128_SHA, SSL_ALLOWED, PR_TRUE, PR_FALSE}, { TLS_RSA_WITH_RC4_128_MD5, SSL_ALLOWED, PR_TRUE, PR_FALSE}, if (config_match(suite, SSL_ALLOWED, PR_TRUE, &ss->vrange, ss)) { The same cipher suites enabled though the order is different.
The previous build incorrectly used a higher value of SSL_DH_MIN_P_BITS than we had agreed to use previously. The build -5 will restore the value to 768 as used in the previously released build.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-0684.html