Uprev NSS to 3.23 on iOS

Uprev NSS to 3.23 on iOS

R=svaldez@chromium.org
BUG=600619
Committed: https://crrev.com/c8191e72b96b9007695a9852142d6331ac22632d
Cr-Commit-Position: refs/heads/master@{#385370}

[Ryan Sleevi, 2016-03-30 02:07:23]

rsleevi@chromium.org changed reviewers:
+ rch@chromium.org, svaldez@chromium.org

[Ryan Sleevi, 2016-03-30 02:07:24]

rch: for the QUIC changes. Should be a no-op
svaldez: Everything else
david: FYI

I'm sending this out early, since it's a big patch. The only remaining work I
have is
1) Update the patch files from the git repo that sourced these
2) Check yet-another-time to make sure I got all of the patches correct and in
place

Steven, this is a huge and gross change largely because of the fact that NSS did
a clang-format in between these runs, so... it's messy. To simplify things,
especially with the TLS 1.3 changes, I ended up removing the platform client
auth (since that's only used on iOS) and removing the other platforms from the
build files. This helped prune several patches.

My suggestion for how best to review this is:
1) Examine the patches (aka the things not yet uploaded; as such, you can ignore
this for now :P)
2) Download the raw patchset, apply to a local git tree (e.g. "git cl patch
..."), and then view with an aggressive whitespace-suppression (git diff -w),
which will hide most (but not all) of the clang formats.

Other than that, we'll let the waterfalls sort it out :)

[Ryan Sleevi, 2016-03-30 02:09:05]

On 2016/03/30 02:07:24, Ryan Sleevi wrote:
> Steven, this is a huge and gross change largely because of the fact that NSS
did
> a clang-format in between these runs, so... it's messy. To simplify things,
> especially with the TLS 1.3 changes, I ended up removing the platform client
> auth (since that's only used on iOS) and removing the other platforms from the
> build files. This helped prune several patches.

That is, because NSS is only used on iOS and we never supported client on on
iOS.

Anyways, rch is good to review now, you're able to review now (ignoring the
patches) by using local viewing, otherwise, feel free to sit on this until you
get another update of the patches being uploaded (after I've vetted everything)

[davidben, 2016-03-30 18:39:24]

davidben@chromium.org changed reviewers:
+ davidben@chromium.org

[davidben, 2016-03-30 18:39:25]

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
Oof, I hadn't realized we actually supported ChaCha20-Poly1305 on NSS in QUIC
too when I suggested we remove that patch. I think this would have to switch to
this cipher being disabled and chacha20_poly1305_rfc7539_decrypter_nss.cc being
enabled.

rch: What is the state of chacha20_poly1305_rfc7539_decrypter_*.cc? I assume the
servers all speak both variants now, so it's okay if any iOS code switches from
only supporting the old to only supporting the new?

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:40:
nss_aead_params->ulNonceLen = nonce.size();
This would be contingent on a src/third_party/nss DEPS roll, right? Not a
src/net/third_party/nss update. So I think this file's changes want to be in the
CL that updates DEPS.

https://codereview.chromium.org/1844813002/diff/1/net/socket/nss_ssl_util.cc
File net/socket/nss_ssl_util.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/socket/nss_ssl_util.cc#...
net/socket/nss_ssl_util.cc:153: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, 0,
(FWIW, BoringSSL does not expose this one. Probably not worth fussing over
though.)

[Ryan Sleevi, 2016-03-31 02:52:58]

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
On 2016/03/30 18:39:25, davidben wrote:
> Oof, I hadn't realized we actually supported ChaCha20-Poly1305 on NSS in QUIC
> too when I suggested we remove that patch. I think this would have to switch
to
> this cipher being disabled and chacha20_poly1305_rfc7539_decrypter_nss.cc
being
> enabled.
> 
> rch: What is the state of chacha20_poly1305_rfc7539_decrypter_*.cc? I assume
the
> servers all speak both variants now, so it's okay if any iOS code switches
from
> only supporting the old to only supporting the new?

Do we have tests that cover the old behaviour?

And yeah, I missed that the implementation in NSS slightly differs, to reflect
the RFC status. So... rch, advice on what needs to change here? Do I need to
create a new broken_chacha patch to hack in the old mechanism?

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:40:
nss_aead_params->ulNonceLen = nonce.size();
On 2016/03/30 18:39:25, davidben wrote:
> This would be contingent on a src/third_party/nss DEPS roll, right? Not a
> src/net/third_party/nss update. So I think this file's changes want to be in
the
> CL that updates DEPS.

Correct. Sorry, I didn't upload the DEPS bit yet, because the two had to be kept
in lock-step to run unittests, and this was the more time consuming one.

[Ryan Sleevi, 2016-03-31 03:40:18]

Steven: Patches are now uploaded, which should hopefully make it much easier to
review (thankfully, Rietveld's different-color highlighting for whitespace-only
changes will help here). This helps you make sure that structurally, the patches
themselves were maintained.

There is the bigger question about things like behaviour that changed in
upstream NSS 3.23:

NSS 3.22
- Added support for RSA-PSS (*cough* rch *cough*)
- SCT support was upstreamed

NSS 3.22.1
- All of PR_GetEnv has been changed to PR_GetEnvSecure because Red Hat and suid

NSS 3.22.2
- ASN.1 fixes

NSS 3.23
- ChaCha20/Poly1305 work upstreamed
- TLS extension reordering work to avoid WebSphere/Tomcat issues was upstreamed
- Root CA stuff
- ASN.1 fixes

[davidben, 2016-03-31 05:23:00]

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
On 2016/03/31 02:52:58, Ryan Sleevi wrote:
> On 2016/03/30 18:39:25, davidben wrote:
> > Oof, I hadn't realized we actually supported ChaCha20-Poly1305 on NSS in
QUIC
> > too when I suggested we remove that patch. I think this would have to switch
> to
> > this cipher being disabled and chacha20_poly1305_rfc7539_decrypter_nss.cc
> being
> > enabled.
> > 
> > rch: What is the state of chacha20_poly1305_rfc7539_decrypter_*.cc? I assume
> the
> > servers all speak both variants now, so it's okay if any iOS code switches
> from
> > only supporting the old to only supporting the new?
> 
> Do we have tests that cover the old behaviour?

I believe both sets of ChaCha20Poly1305 classes in QUIC have tests with test
vectors, so we'd notice. Note that the standardized variant is
chacha20_poly1305_rfc7539_*.cc. So I think you'd want to disable this set of
files and enable the other one. There's a
ChaCha20Poly1305Rfc7539Encrypter::IsSupported that I believe you want to move
over to ChaCha20Poly1305Encrypter instead.

> And yeah, I missed that the implementation in NSS slightly differs, to reflect
> the RFC status. So... rch, advice on what needs to change here? Do I need to
> create a new broken_chacha patch to hack in the old mechanism?

I'm not rch, but I would vote we don't try to support both variants in
third_party/nss and instead only support the RFC construction. The RFC
construction was added a while ago, so I assume this is fine now. (Get rch to
confirm, of course.)

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:40:
nss_aead_params->ulNonceLen = nonce.size();
On 2016/03/31 02:52:58, Ryan Sleevi wrote:
> On 2016/03/30 18:39:25, davidben wrote:
> > This would be contingent on a src/third_party/nss DEPS roll, right? Not a
> > src/net/third_party/nss update. So I think this file's changes want to be in
> the
> > CL that updates DEPS.
> 
> Correct. Sorry, I didn't upload the DEPS bit yet, because the two had to be
kept
> in lock-step to run unittests, and this was the more time consuming one.

Got it.

[svaldez, 2016-03-31 15:30:51]

On 2016/03/31 05:23:00, davidben wrote:
>
https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
> File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):
> 
>
https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
> net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
> AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
> On 2016/03/31 02:52:58, Ryan Sleevi wrote:
> > On 2016/03/30 18:39:25, davidben wrote:
> > > Oof, I hadn't realized we actually supported ChaCha20-Poly1305 on NSS in
> QUIC
> > > too when I suggested we remove that patch. I think this would have to
switch
> > to
> > > this cipher being disabled and chacha20_poly1305_rfc7539_decrypter_nss.cc
> > being
> > > enabled.
> > > 
> > > rch: What is the state of chacha20_poly1305_rfc7539_decrypter_*.cc? I
assume
> > the
> > > servers all speak both variants now, so it's okay if any iOS code switches
> > from
> > > only supporting the old to only supporting the new?
> > 
> > Do we have tests that cover the old behaviour?
> 
> I believe both sets of ChaCha20Poly1305 classes in QUIC have tests with test
> vectors, so we'd notice. Note that the standardized variant is
> chacha20_poly1305_rfc7539_*.cc. So I think you'd want to disable this set of
> files and enable the other one. There's a
> ChaCha20Poly1305Rfc7539Encrypter::IsSupported that I believe you want to move
> over to ChaCha20Poly1305Encrypter instead.
> 
> > And yeah, I missed that the implementation in NSS slightly differs, to
reflect
> > the RFC status. So... rch, advice on what needs to change here? Do I need to
> > create a new broken_chacha patch to hack in the old mechanism?
> 
> I'm not rch, but I would vote we don't try to support both variants in
> third_party/nss and instead only support the RFC construction. The RFC
> construction was added a while ago, so I assume this is fine now. (Get rch to
> confirm, of course.)
> 
>
https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
> net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:40:
> nss_aead_params->ulNonceLen = nonce.size();
> On 2016/03/31 02:52:58, Ryan Sleevi wrote:
> > On 2016/03/30 18:39:25, davidben wrote:
> > > This would be contingent on a src/third_party/nss DEPS roll, right? Not a
> > > src/net/third_party/nss update. So I think this file's changes want to be
in
> > the
> > > CL that updates DEPS.
> > 
> > Correct. Sorry, I didn't upload the DEPS bit yet, because the two had to be
> kept
> > in lock-step to run unittests, and this was the more time consuming one.
> 
> Got it.

Looks like you actually have to use "apply_issue.py -i [Issue #]" since the
patchset is too large for 'git cl patch' to work.

[svaldez, 2016-04-01 19:50:01]

Rough lgtm. The nits are probably not worth doing anything about to prevent more
forking/patching. I've done a pass over everything except the new tls13 files,
which might not matter now, though I'll try getting through them today. 

Also do we actually ever build through the Makefiles? There are some files
removed from the gyp build files that are now only referred as part of the
Makefile.

https://codereview.chromium.org/1844813002/diff/10001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/ssl3con.c (right):

https://codereview.chromium.org/1844813002/diff/10001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:6637: if (isTLS13) {
Looks like dead code, probably not worth forking.

https://codereview.chromium.org/1844813002/diff/10001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/sslsock.c (right):

https://codereview.chromium.org/1844813002/diff/10001/net/third_party/nss/ssl...
net/third_party/nss/ssl/sslsock.c:1552: return ssl_Init(); /* make sure the
policies have bee loaded */
*been

[svaldez, 2016-04-01 20:50:24]

TLS1.3 files seem fine. LGTM.

[Ryan Hamilton, 2016-04-03 23:44:11]

net/quic/ LGTM

[Ryan Sleevi, 2016-04-04 01:47:15]

On 2016/04/03 23:44:11, Ryan Hamilton wrote:
> net/quic/ LGTM

Rch: Could you please re-read the review remarks and chime in? As pointed out by
Davidben, the //net/quic changes are probably not correct.

[Ryan Hamilton, 2016-04-04 14:37:01]

Once this lands, will we be able to implement PSS signing on nSS?

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
On 2016/03/31 05:23:00, davidben (OOO 4-4 to 4-11) wrote:
> On 2016/03/31 02:52:58, Ryan Sleevi wrote:
> > On 2016/03/30 18:39:25, davidben wrote:
> > > Oof, I hadn't realized we actually supported ChaCha20-Poly1305 on NSS in
> QUIC
> > > too when I suggested we remove that patch. I think this would have to
switch
> > to
> > > this cipher being disabled and chacha20_poly1305_rfc7539_decrypter_nss.cc
> > being
> > > enabled.
> > > 
> > > rch: What is the state of chacha20_poly1305_rfc7539_decrypter_*.cc? I
assume
> > the
> > > servers all speak both variants now, so it's okay if any iOS code switches
> > from
> > > only supporting the old to only supporting the new?
> > 
> > Do we have tests that cover the old behaviour?
> 
> I believe both sets of ChaCha20Poly1305 classes in QUIC have tests with test
> vectors, so we'd notice. 

Yes, that's right. Do the unit tests pass with this change?

> Note that the standardized variant is
> chacha20_poly1305_rfc7539_*.cc. So I think you'd want to disable this set of
> files and enable the other one. There's a
> ChaCha20Poly1305Rfc7539Encrypter::IsSupported that I believe you want to move
> over to ChaCha20Poly1305Encrypter instead.

*nod*

> > And yeah, I missed that the implementation in NSS slightly differs, to
reflect
> > the RFC status. So... rch, advice on what needs to change here? Do I need to
> > create a new broken_chacha patch to hack in the old mechanism?
> 
> I'm not rch, but I would vote we don't try to support both variants in
> third_party/nss and instead only support the RFC construction. The RFC
> construction was added a while ago, so I assume this is fine now. (Get rch to
> confirm, of course.)

Yes, I think that should be fine. Since QUIC is not used for web browsing on iOS
Chrome, we don't actually enable QUIC on iOS any longer. We will, however, use
QUIC on iOS for Cronet.

[davidben, 2016-04-04 14:55:53]

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
On 2016/04/04 14:37:01, Ryan Hamilton wrote:
> Yes, I think that should be fine. Since QUIC is not used for web browsing on
iOS
> Chrome, we don't actually enable QUIC on iOS any longer. We will, however, use
> QUIC on iOS for Cronet.

In that case, should we just take the code out? We can land that as a
prerequisite to this roll and avoid having to fuss with stuff. QUIC/iOS/Cronet
would be using the BoringSSL port anyway. Or is there still some intermediate
stage where we care about QUIC/iOS/NSS right now? (I notice you say "will"
rather than "do", so I'm guessing no?)

[Ryan Hamilton, 2016-04-04 16:00:50]

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):

https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
On 2016/04/04 14:55:52, davidben (OOO 4-4 to 4-11) wrote:
> On 2016/04/04 14:37:01, Ryan Hamilton wrote:
> > Yes, I think that should be fine. Since QUIC is not used for web browsing on
> iOS
> > Chrome, we don't actually enable QUIC on iOS any longer. We will, however,
use
> > QUIC on iOS for Cronet.
> 
> In that case, should we just take the code out? We can land that as a
> prerequisite to this roll and avoid having to fuss with stuff. QUIC/iOS/Cronet
> would be using the BoringSSL port anyway. Or is there still some intermediate
> stage where we care about QUIC/iOS/NSS right now? (I notice you say "will"
> rather than "do", so I'm guessing no?)

Perhaps I should have said "do". I know that we have external cronet customers
actively trying to get Cronet + QUIC + iOS working. I'm not sure if they've
succeeded, but they're trying. If they're not working yet, they will be RSN, as
I understand it. So I don't *think* we want to remove this code. But switching
from agl-ChaCha20/Poly1305 to RFC-ChaCha20/Poly1305 on iOS should be fine.

When you say that "QUIC/iOS/Cronet would be using the BoringSSL port anyway" do
you mean that is already happening, or that it will be happening soon? If this
is already happening, then perhaps we could remove this code. What's the plan
for iOS + Chrome? Will that be switching to BoringSSL too?

[svaldez1, 2016-04-04 17:03:59]

On 2016/04/04 16:00:50, Ryan Hamilton wrote:
>
https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
> File net/quic/crypto/chacha20_poly1305_decrypter_nss.cc (right):
> 
>
https://codereview.chromium.org/1844813002/diff/1/net/quic/crypto/chacha20_po...
> net/quic/crypto/chacha20_poly1305_decrypter_nss.cc:21: :
> AeadBaseDecrypter(CKM_NSS_CHACHA20_POLY1305,
> On 2016/04/04 14:55:52, davidben (OOO 4-4 to 4-11) wrote:
> > On 2016/04/04 14:37:01, Ryan Hamilton wrote:
> > > Yes, I think that should be fine. Since QUIC is not used for web browsing
on
> > iOS
> > > Chrome, we don't actually enable QUIC on iOS any longer. We will, however,
> use
> > > QUIC on iOS for Cronet.
> > 
> > In that case, should we just take the code out? We can land that as a
> > prerequisite to this roll and avoid having to fuss with stuff.
QUIC/iOS/Cronet
> > would be using the BoringSSL port anyway. Or is there still some
intermediate
> > stage where we care about QUIC/iOS/NSS right now? (I notice you say "will"
> > rather than "do", so I'm guessing no?)
> 
> Perhaps I should have said "do". I know that we have external cronet customers
> actively trying to get Cronet + QUIC + iOS working. I'm not sure if they've
> succeeded, but they're trying. If they're not working yet, they will be RSN,
as
> I understand it. So I don't *think* we want to remove this code. But switching
> from agl-ChaCha20/Poly1305 to RFC-ChaCha20/Poly1305 on iOS should be fine.
> 
> When you say that "QUIC/iOS/Cronet would be using the BoringSSL port anyway"
do
> you mean that is already happening, or that it will be happening soon? If this
> is already happening, then perhaps we could remove this code. What's the plan
> for iOS + Chrome? Will that be switching to BoringSSL too?

Currently I don't believe there are plans to have Cronet+NSS and there is
already a BoringSSL+Cronet version that exists, modulo getting the build story
sorted out. The slightly longer term is to get Chrome to use BoringSSL, once we
get Cert Verification to a state that is suitable for Chrome.

[Ryan Sleevi, 2016-04-05 03:21:33]

On 2016/04/01 19:50:01, svaldez wrote:
> Rough lgtm. The nits are probably not worth doing anything about to prevent
more
> forking/patching. I've done a pass over everything except the new tls13 files,
> which might not matter now, though I'll try getting through them today. 
> 
> Also do we actually ever build through the Makefiles? There are some files
> removed from the gyp build files that are now only referred as part of the
> Makefile.

We do not. I left them from upstream, but yes, there's now definitely
unnecessary files. The way we've done it is just copy over ssl/, so that seemed
better/easier than doing per-file restrictions (like we do in the
third_party/nss, which is a nightmare). The same is true for third-party NSPR

[Ryan Sleevi, 2016-04-05 03:21:48]

Rebased onto RCH's https://codereview.chromium.org/1854273002

[Ryan Sleevi, 2016-04-05 03:23:28]

Description was changed from

==========
Uprev NSS to 3.23 on iOS

BUG=
==========

to

==========
Uprev NSS to 3.23 on iOS

R=svaldez@chromium.org
BUG=600619
==========

[Ryan Sleevi, 2016-04-05 18:42:45]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-05 18:43:09]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1844813002/30001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1844813002/30001

[commit-bot: I haz the power, 2016-04-05 18:49:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-05 18:49:37]

Dry run: Try jobs failed on following builders:
  ios_rel_device_gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_gn...)

[Ryan Sleevi, 2016-04-06 01:33:52]

Dirk: Would you be willing to stamp the GN build? We're in the processing of
removing NSS for all platforms, so there's no desire to support building (hence
the GN excision, which matches GYP)

[Ryan Sleevi, 2016-04-06 01:34:09]

rsleevi@chromium.org changed reviewers:
+ dpranke@chromium.org

[Ryan Sleevi, 2016-04-06 01:34:36]

OK, for realsy-reals adding Dirk. Hopefully a rubberstamp, see previous comment.

[Dirk Pranke, 2016-04-06 01:40:59]

//build/secondary lgtm.

[Ryan Sleevi, 2016-04-06 02:13:49]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-04-06 02:13:51]

The patchset sent to the CQ was uploaded after l-g-t-m from
svaldez@chromium.org, rch@chromium.org
Link to the patchset: https://codereview.chromium.org/1844813002/#ps60001
(title: "One more GN fix")

[commit-bot: I haz the power, 2016-04-06 02:14:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1844813002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1844813002/60001

[commit-bot: I haz the power, 2016-04-06 02:22:47]

Description was changed from

==========
Uprev NSS to 3.23 on iOS

R=svaldez@chromium.org
BUG=600619
==========

to

==========
Uprev NSS to 3.23 on iOS

R=svaldez@chromium.org
BUG=600619
==========

[commit-bot: I haz the power, 2016-04-06 02:22:49]

Committed patchset #7 (id:60001)

[commit-bot: I haz the power, 2016-04-06 02:24:01]

Description was changed from

==========
Uprev NSS to 3.23 on iOS

R=svaldez@chromium.org
BUG=600619
==========

to

==========
Uprev NSS to 3.23 on iOS

R=svaldez@chromium.org
BUG=600619

Committed: https://crrev.com/c8191e72b96b9007695a9852142d6331ac22632d
Cr-Commit-Position: refs/heads/master@{#385370}
==========

[commit-bot: I haz the power, 2016-04-06 02:24:03]

Patchset 7 (id:??) landed as
https://crrev.com/c8191e72b96b9007695a9852142d6331ac22632d
Cr-Commit-Position: refs/heads/master@{#385370}