Sign CertificateVerify messages on a background thread.

net/BUILD.gn

Index: net/BUILD.gn
diff --git a/net/BUILD.gn b/net/BUILD.gn
index e8a8da64935c7ece78c1477e28e44dfdd5c7140c..dfade92bbcce06c47fb288f2e7549bdd550437f2 100644
--- a/net/BUILD.gn
+++ b/net/BUILD.gn
@@ -244,21 +244,13 @@ component("net") {
       "socket/ssl_client_socket_openssl.h",
       "socket/ssl_server_socket_openssl.cc",
       "socket/ssl_server_socket_openssl.h",
-      "ssl/openssl_platform_key.h",
-      "ssl/openssl_platform_key_nss.cc",
       "ssl/openssl_ssl_util.cc",
       "ssl/openssl_ssl_util.h",
       "ssl/ssl_client_session_cache_openssl.cc",
       "ssl/ssl_client_session_cache_openssl.h",

[Ryan Sleevi, 2015/06/12 23:37:19]

no files to add?

[davidben, 2015/06/15 21:28:24]

The new interfaces aren't OpenSSL-specific (hence the name), so I figured it
wasn't worth the strangeness of having non-OpenSSL files being excluded from the
various OpenSSL bits. Instead its:

- SSLClientSocketOpenSSL depends on the SSLPrivateKey interface always.
- SSLPrivateKey isn't OpenSSL-specific, neither is ThreadedSSLPrivateKey. They
happen not to be used in the remaining NSS ports, but hopefully the static
linker will make them fall away?
- ThreadedSSLPrivateKey isn't specific to OpenSSL
- SSLPlatformKey{Mac,Win} implement a non-OpenSSL-specific interface. They
depend very slightly on OpenSSL as an implementation detail, but that's a fine
assumption today. Conceivably they could have a little #ifdef if we still cared.
- SSLPlatformKeyNSS can probably be implemented without any OpenSSL dependency
to avoid making life complicated should we stick with this static linker route.

I can put those back though. I think it's a question of which is the least of
the three evils:
- Name these things with "openssl" in the name even though it's not
OpenSSL-specific and we hope to surface SSLPrivateKey in //net's public
interface someday.
- Name them as-is, but add build exclusions for them, making them use_openssl
build-exclusions for non-OpenSSL-named files. With the understanding that we'll
have to take ssl_private_key.h out of the exclusions later when we surface
SSLPrivateKey via //net's public interface because switching iOS to BoringSSL
isn't a blocker for that refactor.
- Name them as-is and don't include build exclusions. Each file's inclusion is
locally understandable, but we somewhat prefer the static linker to drop things
on the floor.

[Ryan Sleevi, 2015/06/15 22:35:27]

I'm least keen on this solution, and I don't think it encourages good build-file
health.

If files aren't used, we should just explicitly exclude them. So the
SSLPrivateKey, the SSLPlatformKey, and the ThreadedSSLPrivateKey all get
excluded from use_nss builds unless/until we switch NSS to use them.

So that's your option #2, and is the better route IMO.

[davidben, 2015/06/18 21:58:36]

Done.

     ]
-    if (is_mac) {
-      sources -= [ "ssl/openssl_platform_key_mac.cc" ]
-    }
     if (is_win) {
-      sources -= [
-        "cert/sha256_legacy_support_openssl_win.cc",
-        "ssl/openssl_platform_key_win.cc",
-      ]
+      sources -= [ "cert/sha256_legacy_support_openssl_win.cc" ]
     }
   }
 
@@ -338,9 +330,7 @@ component("net") {
         "ssl/client_cert_store_chromeos.h",
       ]
     }
-    if (use_openssl) {
-      sources -= [ "ssl/openssl_platform_key_nss.cc" ]
-    }
+    sources -= [ "ssl/ssl_platform_key_nss.cc" ]
   } else if (use_openssl) {
     # client_cert_store_nss.c requires NSS_CmpCertChainWCANames from NSS's
     # libssl, but our bundled copy is not built in OpenSSL ports. Pull that file