BASELINE: Update Chromium to 53.0.2785.41

Also adds a few extra files for extensions.

Change-Id: Iccdd55d98660903331cf8b7b29188da781830af4
Reviewed-by: Michael Brüning <michael.bruning@qt.io>

3 files changed, 18 insertions, 21 deletions

diff --git a/chromium/components/webcrypto/BUILD.gn b/chromium/components/webcrypto/BUILD.gn
index d824d54ca21..91ad2c8468a 100644
--- a/chromium/components/webcrypto/BUILD.gn
+++ b/chromium/components/webcrypto/BUILD.gn
@@ -109,10 +109,7 @@ source_set("fuzzer_support") {
     ":webcrypto",
     "//crypto",
     "//crypto:platform",
-
-    # The "blink_for_unittests" includes a dependency on Mojo, which otherwise
-    # public:blink lacks and would result in a linker error.
-    "//third_party/WebKit/public:blink_for_unittests",
+    "//third_party/WebKit/public:blink",
 
     # This contains a helper function for initializing Blink (needed for
     # PartitionAlloc initialization).
diff --git a/chromium/components/webcrypto/blink_key_handle.cc b/chromium/components/webcrypto/blink_key_handle.cc
index 012c7c0b7ba..65825a43ae8 100644
--- a/chromium/components/webcrypto/blink_key_handle.cc
+++ b/chromium/components/webcrypto/blink_key_handle.cc
@@ -26,6 +26,9 @@ class AsymKey;
 // 'raw', 'pkcs8', or 'spki' format. This is to allow structured cloning of
 // keys to be done synchronously from the target Blink thread, without having to
 // lock access to the key throughout the code.
+//
+// TODO(eroman): Should be able to do the key export needed for structured
+//               clone synchronously.
 class Key : public blink::WebCryptoKeyHandle {
  public:
   explicit Key(const CryptoData& serialized_key_data)
@@ -63,12 +66,14 @@ class SymKey : public Key {
 
 class AsymKey : public Key {
  public:
+  // After construction the |pkey| should NOT be mutated.
   AsymKey(crypto::ScopedEVP_PKEY pkey,
           const std::vector<uint8_t>& serialized_key_data)
       : Key(CryptoData(serialized_key_data)), pkey_(std::move(pkey)) {}
 
   AsymKey* AsAsymKey() override { return this; }
 
+  // The caller should NOT mutate this EVP_PKEY.
   EVP_PKEY* pkey() { return pkey_.get(); }
 
  private:
diff --git a/chromium/components/webcrypto/webcrypto_impl.cc b/chromium/components/webcrypto/webcrypto_impl.cc
index 5712854e557..7986b774114 100644
--- a/chromium/components/webcrypto/webcrypto_impl.cc
+++ b/chromium/components/webcrypto/webcrypto_impl.cc
@@ -36,10 +36,7 @@ namespace {
 // ---------------------
 //
 // WebCrypto operations can be slow. For instance generating an RSA key can
-// seconds.
-//
-// Moreover the underlying crypto libraries are not threadsafe when operating
-// on the same key.
+// take seconds.
 //
 // The strategy used here is to run a sequenced worker pool for all WebCrypto
 // operations (except structured cloning). This same pool is also used by
@@ -47,26 +44,24 @@ namespace {
 //
 // A few notes to keep in mind:
 //
-// * PostTaskAndReply() cannot be used for two reasons:
-//
-//   (1) Blink web worker threads do not have an associated message loop so
-//       construction of the reply callback will crash.
+// * PostTaskAndReply() is not used because of how it handles failures -- it
+//   leaks the callback when failing to post back to the origin thread.
 //
-//   (2) PostTaskAndReply() handles failure posting the reply by leaking the
-//       callback, rather than destroying it. In the case of Web Workers this
-//       condition is reachable via normal execution, since Web Workers can
-//       be stopped before the WebCrypto operation has finished. A policy of
-//       leaking would therefore be problematic.
+//   This is a problem since WebCrypto may be called from WebWorker threads,
+//   which may be aborted at any time. Leaking would be undesirable, and
+//   reachable in practice.
 //
 // * blink::WebArrayBuffer is NOT threadsafe, and should therefore be allocated
-//   on the target Blink thread.
+//   only on the target Blink thread.
 //
 //   TODO(eroman): Is there any way around this? Copying the result between
 //                 threads is silly.
 //
-// * WebCryptoAlgorithm and WebCryptoKey are threadsafe (however the key's
-//   handle(), which wraps an OpenSSL type, may not be and should only be
-//   used from the webcrypto thread).
+// * WebCryptoAlgorithm and WebCryptoKey are threadsafe, by virtue of being
+//   immutable. Internally asymmetric WebCryptoKeys wrap BoringSSL's EVP_PKEY.
+//   These are safe to use for BoringSSL operations across threads, provided
+//   the internals of the EVP_PKEY are not mutated (they never should be
+//   following ImportKey()).
 //
 // * blink::WebCryptoResult is not threadsafe and should only be operated on
 //   the target Blink thread. HOWEVER, it is safe to delete it from any thread.