Removing NSS files and USE_OPENSSL flag

This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
TBR=kelvinp@chromium.org

Committed: https://crrev.com/2135be5210856ba79bdb774166af869342c5dddf
Cr-Commit-Position: refs/heads/master@{#388517}

[svaldez, 2016-04-14 17:09:39]

Description was changed from

==========
Removing USE_OPENSSL

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

to

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=591545
==========

[svaldez, 2016-04-14 17:09:40]

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

[svaldez, 2016-04-14 17:20:53]

Description was changed from

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=591545
==========

to

==========
This removes most of the NSS files and both the use_openssl
build argument and macro since we no longer have any
platforms using NSS for crypto/SSL.

BUG=591545
==========

[svaldez, 2016-04-14 17:24:06]

Description was changed from

==========
This removes most of the NSS files and both the use_openssl
build argument and macro since we no longer have any
platforms using NSS for crypto/SSL.

BUG=591545
==========

to

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=591545
==========

[svaldez, 2016-04-18 14:08:51]

I keep forgetting that setting an R= line on CLs doesn't actually mail them
out...

[Ryan Sleevi, 2016-04-18 14:23:31]

I made it about halfway through double checking.

A recurring theme is the need to fix the headers now that you're removing the
'platform' guards. Could you take a stab at that and then I'll do a second pass.

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode78
crypto/BUILD.gn:78: "third_party/nss/chromium-sha256.h",
Why?

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode79
crypto/BUILD.gn:79: "third_party/nss/sha512.cc",
Why? Now that we're using BoringSSl, we shouldn't need a hermetic SHA-256
implementation, should we?

https://codereview.chromium.org/1882433002/diff/60001/crypto/crypto.gyp
File crypto/crypto.gyp (right):

https://codereview.chromium.org/1882433002/diff/60001/crypto/crypto.gyp#newco...
crypto/crypto.gyp:167: # for the helper.
Update

https://codereview.chromium.org/1882433002/diff/60001/net/cert/test_root_cert...
File net/cert/test_root_certs_unittest.cc (right):

https://codereview.chromium.org/1882433002/diff/60001/net/cert/test_root_cert...
net/cert/test_root_certs_unittest.cc:77: #endif
We can just delete this (3.17.3 is the new minimum)

https://codereview.chromium.org/1882433002/diff/60001/net/http/des.cc
File net/http/des.cc (left):

https://codereview.chromium.org/1882433002/diff/60001/net/http/des.cc#oldcode96
net/http/des.cc:96: #elif defined(OS_IOS)
I'm torn on this.

Semantically, your change is correct. However, objectively, the iOS CCrypto code
should be universally faster than BoringSSL code, due to Apple-specific
optimizations here.

I'll LG this, but maybe a conversation worth following-up with David (e.g.
should our BoringSSL-on-iOS code call the CommonCrypto routines on iOS)

https://codereview.chromium.org/1882433002/diff/60001/net/quic/crypto/p256_ke...
File net/quic/crypto/p256_key_exchange.h (right):

https://codereview.chromium.org/1882433002/diff/60001/net/quic/crypto/p256_ke...
net/quic/crypto/p256_key_exchange.h:19: #include "crypto/scoped_openssl_types.h"
Fix sorting

[svaldez, 2016-04-18 15:09:35]

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode78
crypto/BUILD.gn:78: "third_party/nss/chromium-sha256.h",
On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> Why?

nacl_win64 seems to need it.

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode79
crypto/BUILD.gn:79: "third_party/nss/sha512.cc",
On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> Why? Now that we're using BoringSSl, we shouldn't need a hermetic SHA-256
> implementation, should we?

nacl_win64 seems to need it.

https://codereview.chromium.org/1882433002/diff/60001/crypto/crypto.gyp
File crypto/crypto.gyp (right):

https://codereview.chromium.org/1882433002/diff/60001/crypto/crypto.gyp#newco...
crypto/crypto.gyp:167: # for the helper.
On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> Update

Done.

https://codereview.chromium.org/1882433002/diff/60001/net/cert/test_root_cert...
File net/cert/test_root_certs_unittest.cc (right):

https://codereview.chromium.org/1882433002/diff/60001/net/cert/test_root_cert...
net/cert/test_root_certs_unittest.cc:77: #endif
On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> We can just delete this (3.17.3 is the new minimum)

Done.

https://codereview.chromium.org/1882433002/diff/60001/net/http/des.cc
File net/http/des.cc (left):

https://codereview.chromium.org/1882433002/diff/60001/net/http/des.cc#oldcode96
net/http/des.cc:96: #elif defined(OS_IOS)
On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> I'm torn on this.
> 
> Semantically, your change is correct. However, objectively, the iOS CCrypto
code
> should be universally faster than BoringSSL code, due to Apple-specific
> optimizations here.
> 
> I'll LG this, but maybe a conversation worth following-up with David (e.g.
> should our BoringSSL-on-iOS code call the CommonCrypto routines on iOS)

Acknowledged.

https://codereview.chromium.org/1882433002/diff/60001/net/quic/crypto/p256_ke...
File net/quic/crypto/p256_key_exchange.h (right):

https://codereview.chromium.org/1882433002/diff/60001/net/quic/crypto/p256_ke...
net/quic/crypto/p256_key_exchange.h:19: #include "crypto/scoped_openssl_types.h"
On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> Fix sorting

Done.

[Ryan Sleevi, 2016-04-18 15:31:40]

LGTM, but could you double check that the sorting order is consistent with
sort-headers.py? I would think because we're doing the BoringSSL includes 'as
if' they were System includes (David had a change to change this, but it's
stalled), I think they should be appearing in the C system headers section (e.g.
before C++ system headers)

You can use
https://code.google.com/p/chromium/codesearch#chromium/src/tools/git/for-all-...
to make this easy.

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode79
crypto/BUILD.gn:79: "third_party/nss/sha512.cc",
On 2016/04/18 15:09:35, svaldez wrote:
> On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> > Why? Now that we're using BoringSSl, we shouldn't need a hermetic SHA-256
> > implementation, should we?
> 
> nacl_win64 seems to need it.

I guess put differently, should we have nacl_win64 using a hermetic copy of
BoringSSL's SHA-1/SHA-2 implementation, so that we can reduce the number of
unique implementations we're carrying? I would at least think it'd be more
performant there.

I'm not sure whether we should address that before or after, but I definitely
think we should excise these NSS forks (also the //base/sha1 impl)

[svaldez, 2016-04-18 15:42:11]

On 2016/04/18 15:31:40, Ryan Sleevi wrote:
> LGTM, but could you double check that the sorting order is consistent with
> sort-headers.py? I would think because we're doing the BoringSSL includes 'as
> if' they were System includes (David had a change to change this, but it's
> stalled), I think they should be appearing in the C system headers section
(e.g.
> before C++ system headers)
> 
> You can use
>
https://code.google.com/p/chromium/codesearch#chromium/src/tools/git/for-all-...
> to make this easy.
> 
> https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn
> File crypto/BUILD.gn (right):
> 
>
https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode79
> crypto/BUILD.gn:79: "third_party/nss/sha512.cc",
> On 2016/04/18 15:09:35, svaldez wrote:
> > On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> > > Why? Now that we're using BoringSSl, we shouldn't need a hermetic SHA-256
> > > implementation, should we?
> > 
> > nacl_win64 seems to need it.
> 
> I guess put differently, should we have nacl_win64 using a hermetic copy of
> BoringSSL's SHA-1/SHA-2 implementation, so that we can reduce the number of
> unique implementations we're carrying? I would at least think it'd be more
> performant there.
> 
> I'm not sure whether we should address that before or after, but I definitely
> think we should excise these NSS forks (also the //base/sha1 impl)

sort-headers seems to prefer the current ordering.

Yeah, I think removing the remaining random NSS forks is a good idea, but it
would probably make more sense to remove them as a separate CL instead of mixing
mostly programmatic removal of dead code with changing the actual way hmac_win
and other files are implemented.

[davidben, 2016-04-18 16:25:20]

(Haven't looked at the rest of the CL yet, but this caught my eye. Am happy to
defer to Ryan or find the time to look over it myself.)

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/1882433002/diff/60001/crypto/BUILD.gn#newcode79
crypto/BUILD.gn:79: "third_party/nss/sha512.cc",
On 2016/04/18 15:31:40, Ryan Sleevi wrote:
> On 2016/04/18 15:09:35, svaldez wrote:
> > On 2016/04/18 14:23:30, Ryan Sleevi wrote:
> > > Why? Now that we're using BoringSSl, we shouldn't need a hermetic SHA-256
> > > implementation, should we?
> > 
> > nacl_win64 seems to need it.
> 
> I guess put differently, should we have nacl_win64 using a hermetic copy of
> BoringSSL's SHA-1/SHA-2 implementation, so that we can reduce the number of
> unique implementations we're carrying? I would at least think it'd be more
> performant there.
> 
> I'm not sure whether we should address that before or after, but I definitely
> think we should excise these NSS forks (also the //base/sha1 impl)

This should be excisable, yeah. Either by pulling in BoringSSL (either trusting
the static linker to drop everything else or making yet another bespoke subset)
or using the Windows native one since we no longer support XP. I had a TODO to
deal with it and it slipped through. But I think it makes sense to do that
separately from this CL.

[davidben, 2016-04-18 16:27:12]

https://codereview.chromium.org/1882433002/diff/70001/build/linux/system.gyp
File build/linux/system.gyp (right):

https://codereview.chromium.org/1882433002/diff/70001/build/linux/system.gyp#...
build/linux/system.gyp:1250:
'../../third_party/boringssl/boringssl.gyp:boringssl',
For a follow-up probably since this is already huge (and it may not be worth
bothering with gyp going away), but I think we should remove this from this
target and rename the target to system.gyp:nss. System NSS and
net/third_party/nss had some complex relationship which is why the two were tied
together, but we no longer have that constraint.

[Ryan Sleevi, 2016-04-18 16:39:03]

Oh, I was totally saying "separate patch" - I just wasn't sure if we should do
before or after gutting this.

As for punting to the OS, I don't *think* we want to load CAPI into the SFI
code, for security reasons. But if we are already, ignore me. It may be useful
to have a BoringSSL target in the BoringSSL build files that just built the
SHA-1/SHA-2 bits, but yeah, I won't hijack this CL for that :)

[davidben, 2016-04-18 17:00:45]

On 2016/04/18 16:39:03, Ryan Sleevi wrote:
> Oh, I was totally saying "separate patch" - I just wasn't sure if we should do
> before or after gutting this.
> 
> As for punting to the OS, I don't *think* we want to load CAPI into the SFI
> code, for security reasons. But if we are already, ignore me. It may be useful
> to have a BoringSSL target in the BoringSSL build files that just built the
> SHA-1/SHA-2 bits, but yeah, I won't hijack this CL for that :)

We already are for SHA-1.
https://code.google.com/p/chromium/codesearch#chromium/src/crypto/hmac_win.cc...

Unless this happens lazily and that we're not using the SHA-1 codepath means
CAPI isn't getting loaded?

Either way, I would be overjoyed to lose the last of the *_win.cc files in
//crypto. If no one's complained about binary size with the vendored NSS SHA-256
implementation, I'd be pretty happy to use the BoringSSL one and lose
hmac_win.cc. That leaves symmetric_key_win.cc. I need to double-check, but I
believe that actually is completely unnecessary. It's only getting pulled in by
way of crypto::HMAC::Init(SymmetricKey* key), so this dependency is breakable.
(For instance, we could just have nacl_win64 call BoringSSL's HMAC APIs
directly.)

[davidben, 2016-04-18 19:36:45]

lgtm with a few comments.

+rch as FYI because of net/quic's arrangement with the internal repository.

A note on tracking: I'd probably just close 591545 and file a new bug for the
post-NSS removal cleanup, since we'll have a lot of follow-ups here.

https://codereview.chromium.org/1882433002/diff/70001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/1882433002/diff/70001/crypto/BUILD.gn#newcode254
crypto/BUILD.gn:254: group("platform") {
Another possibility for follow-up: we might want to do away with this target and
have consumers pull in third_party/boringssl and system_nss_no_ssl_config
directly.

https://codereview.chromium.org/1882433002/diff/70001/crypto/symmetric_key.h
File crypto/symmetric_key.h (right):

https://codereview.chromium.org/1882433002/diff/70001/crypto/symmetric_key.h#...
crypto/symmetric_key.h:20: #elif defined(USE_NSS_CERTS)
This looks like I messed up from doing the chimera. We can remove this line and
line 21.

https://codereview.chromium.org/1882433002/diff/70001/net/cert/test_root_cert...
File net/cert/test_root_certs_unittest.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/cert/test_root_cert...
net/cert/test_root_certs_unittest.cc:71: #if defined(USE_NSS_VERIFIER)
I think this is still needed, unless we're finally past this range of versions.

https://codereview.chromium.org/1882433002/diff/70001/net/cert/x509_util_nss.cc
File net/cert/x509_util_nss.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/cert/x509_util_nss....
net/cert/x509_util_nss.cc:1: // Copyright (c) 2012 The Chromium Authors. All
rights reserved.
Should we rename x509_util_nss_certs.cc to x509_util_nss.cc now that this one's
out of the way?

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
File net/quic/crypto/chacha20_poly1305_rfc7539_decrypter.h (right):

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
net/quic/crypto/chacha20_poly1305_rfc7539_decrypter.h:36: static bool
IsSupported();
rch: I believe this can go away now.

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
File net/quic/crypto/chacha20_poly1305_rfc7539_encrypter.h (right):

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
net/quic/crypto/chacha20_poly1305_rfc7539_encrypter.h:34: static bool
IsSupported();
rch: I believe this can go away now.

https://codereview.chromium.org/1882433002/diff/70001/net/quic/quic_stream_fa...
File net/quic/quic_stream_factory.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/quic/quic_stream_fa...
net/quic/quic_stream_factory.cc:688: bool has_aes_hardware_support =
cpu.has_aesni() && cpu.has_avx();
As follow-up: we can probably prune some stuff from base/cpu.h.

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
File net/socket/ssl_client_socket_openssl.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
net/socket/ssl_client_socket_openssl.cc:399: // Note that when USE_OPENSSL is
defined, OSCertHandle is X509*
I think this comment is still valid. It was just never updated for USE_OPENSSL
-> USE_OPENSSL_CERTS. (Though I'm not attached to the comment so feel free to
get rid of it too.)

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
File net/socket/ssl_client_socket_unittest.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
net/socket/ssl_client_socket_unittest.cc:2275: // cert_key_types is currently
only populated on OpenSSL.
Nit: Remove this comment.

[svaldez, 2016-04-18 20:21:40]

https://codereview.chromium.org/1882433002/diff/70001/build/linux/system.gyp
File build/linux/system.gyp (right):

https://codereview.chromium.org/1882433002/diff/70001/build/linux/system.gyp#...
build/linux/system.gyp:1250:
'../../third_party/boringssl/boringssl.gyp:boringssl',
On 2016/04/18 16:27:12, davidben wrote:
> For a follow-up probably since this is already huge (and it may not be worth
> bothering with gyp going away), but I think we should remove this from this
> target and rename the target to system.gyp:nss. System NSS and
> net/third_party/nss had some complex relationship which is why the two were
tied
> together, but we no longer have that constraint.

Acknowledged.

https://codereview.chromium.org/1882433002/diff/70001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/1882433002/diff/70001/crypto/BUILD.gn#newcode254
crypto/BUILD.gn:254: group("platform") {
On 2016/04/18 19:36:45, davidben wrote:
> Another possibility for follow-up: we might want to do away with this target
and
> have consumers pull in third_party/boringssl and system_nss_no_ssl_config
> directly.

Acknowledged.

https://codereview.chromium.org/1882433002/diff/70001/crypto/symmetric_key.h
File crypto/symmetric_key.h (right):

https://codereview.chromium.org/1882433002/diff/70001/crypto/symmetric_key.h#...
crypto/symmetric_key.h:20: #elif defined(USE_NSS_CERTS)
On 2016/04/18 19:36:45, davidben wrote:
> This looks like I messed up from doing the chimera. We can remove this line
and
> line 21.

Done.

https://codereview.chromium.org/1882433002/diff/70001/net/cert/test_root_cert...
File net/cert/test_root_certs_unittest.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/cert/test_root_cert...
net/cert/test_root_certs_unittest.cc:71: #if defined(USE_NSS_VERIFIER)
On 2016/04/18 19:36:45, davidben wrote:
> I think this is still needed, unless we're finally past this range of
versions.

Done.

https://codereview.chromium.org/1882433002/diff/70001/net/cert/x509_util_nss.cc
File net/cert/x509_util_nss.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/cert/x509_util_nss....
net/cert/x509_util_nss.cc:1: // Copyright (c) 2012 The Chromium Authors. All
rights reserved.
On 2016/04/18 19:36:45, davidben wrote:
> Should we rename x509_util_nss_certs.cc to x509_util_nss.cc now that this
one's
> out of the way?

Done.

https://codereview.chromium.org/1882433002/diff/70001/net/quic/quic_stream_fa...
File net/quic/quic_stream_factory.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/quic/quic_stream_fa...
net/quic/quic_stream_factory.cc:688: bool has_aes_hardware_support =
cpu.has_aesni() && cpu.has_avx();
On 2016/04/18 19:36:45, davidben wrote:
> As follow-up: we can probably prune some stuff from base/cpu.h.

Acknowledged.

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
File net/socket/ssl_client_socket_openssl.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
net/socket/ssl_client_socket_openssl.cc:399: // Note that when USE_OPENSSL is
defined, OSCertHandle is X509*
On 2016/04/18 19:36:45, davidben wrote:
> I think this comment is still valid. It was just never updated for USE_OPENSSL
> -> USE_OPENSSL_CERTS. (Though I'm not attached to the comment so feel free to
> get rid of it too.)

Done.

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
File net/socket/ssl_client_socket_unittest.cc (left):

https://codereview.chromium.org/1882433002/diff/70001/net/socket/ssl_client_s...
net/socket/ssl_client_socket_unittest.cc:2275: // cert_key_types is currently
only populated on OpenSSL.
On 2016/04/18 19:36:45, davidben wrote:
> Nit: Remove this comment.

Done.

[Ryan Hamilton, 2016-04-18 21:52:02]

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

[Ryan Hamilton, 2016-04-18 21:52:06]

LGTM, modulo one suggestion to remove some now unused test code. Thanks so much
for doing this!

Should I plan to rename foo_openssl.cc to foo.cc once this lands?

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
File net/quic/crypto/chacha20_poly1305_rfc7539_decrypter.h (right):

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
net/quic/crypto/chacha20_poly1305_rfc7539_decrypter.h:36: static bool
IsSupported();
On 2016/04/18 19:36:45, davidben wrote:
> rch: I believe this can go away now.

GREAT! GREAT! GREAT! GREAT! GREAT! 

I will remove this internally and in Chromium, once your CL lands.

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
File net/quic/crypto/chacha20_poly1305_rfc7539_encrypter.h (right):

https://codereview.chromium.org/1882433002/diff/70001/net/quic/crypto/chacha2...
net/quic/crypto/chacha20_poly1305_rfc7539_encrypter.h:34: static bool
IsSupported();
On 2016/04/18 19:36:45, davidben wrote:
> rch: I believe this can go away now.

ditto

https://codereview.chromium.org/1882433002/diff/80001/net/quic/test_tools/cry...
File net/quic/test_tools/crypto_test_utils_chromium.cc (left):

https://codereview.chromium.org/1882433002/diff/80001/net/quic/test_tools/cry...
net/quic/test_tools/crypto_test_utils_chromium.cc:225: FakeProofSource* source =
new FakeProofSource();
I think you can now remove the FakeProofSource class (and FakeProofVerifier
class below) since they existed be cause we could not generate RSA PSS
signatures on NSS (I think I have that right.

[davidben, 2016-04-18 21:53:53]

On 2016/04/18 21:52:06, Ryan Hamilton wrote:
> Should I plan to rename foo_openssl.cc to foo.cc once this lands?

Yeah, that'll be one of many many follow-ups to be done after this CL. :-) We've
got a lot of foo_openssl.cc that needs to be renamed to or folded into foo.cc.

[svaldez, 2016-04-19 14:21:55]

Description was changed from

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=591545
==========

to

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
==========

[svaldez, 2016-04-19 14:37:13]

svaldez@chromium.org changed reviewers:
+ eugenebut@chromium.org, jochen@chromium.org, kelvinp@chromium.org,
thakis@chromium.org

[svaldez, 2016-04-19 14:37:15]

Hi,

This change removes most of the remaining USE_OPENSSL flags/macros since most of
the NSS code can now be removed. Could you look over the following files and
give OWNERS approval.

thakis:
 build/
 tools/

jochen:
 components/
 content/

eugenebut:
 ios/

kelvinp:
 remoting/

Thanks,
Steven

[Nico, 2016-04-19 14:43:38]

my files lgtm

https://codereview.chromium.org/1882433002/diff/90001/build/common.gypi
File build/common.gypi (left):

https://codereview.chromium.org/1882433002/diff/90001/build/common.gypi#oldco...
build/common.gypi:71: 'use_openssl%': 1,
(nit: i'd remove this variable from this file in a follow-up, in case
configurations you don't know about depend on it. if that's the case you
currently will get your whole cl reverted; if you do this part separately then
you'll only have to reland the change to this file)

[Eugene But (OOO till 7-30), 2016-04-19 15:00:12]

ios lgtm, with possible changes

https://codereview.chromium.org/1882433002/diff/100001/ios/chrome/browser/ios...
File ios/chrome/browser/ios_chrome_io_thread.mm (right):

https://codereview.chromium.org/1882433002/diff/100001/ios/chrome/browser/ios...
ios/chrome/browser/ios_chrome_io_thread.mm:57: #include
"net/cert_net/nss_ocsp.h"
Do you still need this include?

https://codereview.chromium.org/1882433002/diff/100001/ios/crnet/crnet_enviro...
File ios/crnet/crnet_environment.mm (right):

https://codereview.chromium.org/1882433002/diff/100001/ios/crnet/crnet_enviro...
ios/crnet/crnet_environment.mm:29: #include "crypto/nss_util.h"
Do you still need this include?

https://codereview.chromium.org/1882433002/diff/100001/ios/crnet/crnet_enviro...
ios/crnet/crnet_environment.mm:41: #include "net/cert_net/nss_ocsp.h"
And this

https://codereview.chromium.org/1882433002/diff/100001/ios/web/app/web_main_l...
File ios/web/app/web_main_loop.mm (right):

https://codereview.chromium.org/1882433002/diff/100001/ios/web/app/web_main_l...
ios/web/app/web_main_loop.mm:22: #include "crypto/nss_util.h"
Do you still need this include?

[svaldez, 2016-04-19 15:12:26]

https://codereview.chromium.org/1882433002/diff/90001/build/common.gypi
File build/common.gypi (left):

https://codereview.chromium.org/1882433002/diff/90001/build/common.gypi#oldco...
build/common.gypi:71: 'use_openssl%': 1,
On 2016/04/19 14:43:38, Nico wrote:
> (nit: i'd remove this variable from this file in a follow-up, in case
> configurations you don't know about depend on it. if that's the case you
> currently will get your whole cl reverted; if you do this part separately then
> you'll only have to reland the change to this file)

Done.

https://codereview.chromium.org/1882433002/diff/100001/ios/crnet/crnet_enviro...
File ios/crnet/crnet_environment.mm (right):

https://codereview.chromium.org/1882433002/diff/100001/ios/crnet/crnet_enviro...
ios/crnet/crnet_environment.mm:29: #include "crypto/nss_util.h"
On 2016/04/19 15:00:12, Eugene But wrote:
> Do you still need this include?

Done.

https://codereview.chromium.org/1882433002/diff/100001/ios/crnet/crnet_enviro...
ios/crnet/crnet_environment.mm:41: #include "net/cert_net/nss_ocsp.h"
On 2016/04/19 15:00:12, Eugene But wrote:
> And this

Done.

https://codereview.chromium.org/1882433002/diff/100001/ios/web/app/web_main_l...
File ios/web/app/web_main_loop.mm (right):

https://codereview.chromium.org/1882433002/diff/100001/ios/web/app/web_main_l...
ios/web/app/web_main_loop.mm:22: #include "crypto/nss_util.h"
On 2016/04/19 15:00:12, Eugene But wrote:
> Do you still need this include?

Done.

[svaldez, 2016-04-19 15:12:50]

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

[commit-bot: I haz the power, 2016-04-19 15:13:05]

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

[commit-bot: I haz the power, 2016-04-19 15:20:48]

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

[commit-bot: I haz the power, 2016-04-19 15:20:50]

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

[svaldez, 2016-04-19 15:32:18]

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

[commit-bot: I haz the power, 2016-04-19 15:32:32]

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

[commit-bot: I haz the power, 2016-04-19 15:50:36]

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

[commit-bot: I haz the power, 2016-04-19 15:50:39]

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

[svaldez, 2016-04-19 16:22:21]

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

[commit-bot: I haz the power, 2016-04-19 16:22:50]

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

[commit-bot: I haz the power, 2016-04-19 18:54:29]

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

[commit-bot: I haz the power, 2016-04-19 18:54:31]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[jochen (gone - plz use gerrit), 2016-04-20 14:25:03]

lgtm

[svaldez, 2016-04-20 14:37:33]

Description was changed from

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
==========

to

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
TBR=kelvinp@chromium.org
==========

[svaldez, 2016-04-20 14:39:48]

The CQ bit was checked by svaldez@chromium.org

[svaldez, 2016-04-20 14:39:50]

The patchset sent to the CQ was uploaded after l-g-t-m from
davidben@chromium.org, rsleevi@chromium.org, rch@chromium.org,
thakis@chromium.org, eugenebut@chromium.org, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1882433002/#ps160001
(title: "Rebase.")

[commit-bot: I haz the power, 2016-04-20 14:40:06]

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

[commit-bot: I haz the power, 2016-04-20 16:35:03]

Description was changed from

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
TBR=kelvinp@chromium.org
==========

to

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
TBR=kelvinp@chromium.org
==========

[commit-bot: I haz the power, 2016-04-20 16:35:06]

Committed patchset #17 (id:160001)

[commit-bot: I haz the power, 2016-04-22 19:24:12]

Description was changed from

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
TBR=kelvinp@chromium.org
==========

to

==========
This removes most of the NSS files and both the use_openssl build argument and
macro since we no longer have any platforms using NSS for crypto/SSL.

BUG=604728
TBR=kelvinp@chromium.org

Committed: https://crrev.com/2135be5210856ba79bdb774166af869342c5dddf
Cr-Commit-Position: refs/heads/master@{#388517}
==========

[commit-bot: I haz the power, 2016-04-22 19:24:15]

Patchset 17 (id:??) landed as
https://crrev.com/2135be5210856ba79bdb774166af869342c5dddf
Cr-Commit-Position: refs/heads/master@{#388517}