[Downloads] Rework how hashes are calculated for download files.

Prior to this CL, downloads assumed that there would be a stable
serialization of hash state. This serialization was meant to be
persisted and used if the download was subsequently resumed, thus
avoiding rehashing the portion of the download completed so far.

However, there's no standard serialization for SHA256 hash state. Any
change to the serialization format would render any historical data
invalid. While it's possible to come up with a reasonable and stable
format for hash state, the resulting complexity isn't worth it.
Fortunately, the code for persisting the hash state was never written.
Hence it's not too late to change things.

With this CL, downloads will behave as follows with respect to hashes:

* An in-progress download will calculate the hash of the bytes written
  to disk so far using a crypto::SecureHash object using SHA256.

* Progress notifications from DownloadItem / DownloadFile no longer
  report a hash state.

* If the download completes successfully, DownloadFile exposes the
  crypto::SecureHash object representing the final hash state via the
  DownloadDestinationObserver interface. DownloadItemImpl uses this
  object to calculate the final hash which is then made available via
  DownloadItem::GetHash() for completed downloads.

* In the event of an interruption, DownloadFile will expose the
  crypto::SecureHash object representing the hash state.
  DownloadItemImpl uses a clone of the hash state to obtain a SHA256
  hash of the partial data. This hash is available via
  DownloadItem::GetHash() on interrupted downloads. DownloadItemImpl
  also keeps the crypto::SecureHash object in case the download is
  resumed later.

* Resuming downloads pass the crypto::SecureHash object representing the
  partial state via DownloadSaveInfo. If a crypto::SecureHash object
  isn't available (e.g. because the download was restored from history),
  then DownloadItemImpl can optionally pass along a SHA256 hash of the
  partial file. If for some reason, the partial state of the download is
  abandoned (e.g. because of a validation error), then
  DownloadRequestCore destroys the cryto::SecureHash object and
  resets the prefix hash so that the download can restart from the
  beginning.

* When DownloadManagerImpl receives a StartDownload() callback (which
  happens when a response is available for a download request), the
  crypto::SecureHash object passed within DownloadSaveInfo is used to
  construct a new DownloadFile.

* A newly created DownloadFile assumes that a crypto::SecureHash object
  passed to it correctly represents the partial state of the partial
  file.

* In the absence of a crypto::SecureHash object, DownloadFile reads the
  partial file and calculates the partial hash state in a new
  crypto::SecureHash object. If a prefix hash value is available, then
  the hash of the partial file is matched against this prefix hash. A
  mismatch causes a FILE_HASH_MISMATCH error which in turn causes the
  download to abandon its partial state and restart.

These rules establish the following invariants:

* All downloads calculate the SHA256 hash of its contents.

* Regardless of how a download is started or resumed, by the time it is
  completed successfully, DownloadItem::GetHash() correctly reports the
  SHA256 hash of the downloaded bytes.

* Regardless of how a download is started or resumed, an interrupted
  download with a received byte count > 0 will always report the correct
  SHA256 hash of the partial data in DownloadItem::GetHash().

Note that this CL doesn't add code to persist the hash for an
interrupted download. In order to keep the size of the CL sane, the
download history changes are going to be done in a follow up CL.

BUG=7648
BUG=563684

Review URL: https://codereview.chromium.org/1751603002

Cr-Commit-Position: refs/heads/master@{#381158}

1 files changed, 5 insertions, 15 deletions

diff --git a/crypto/secure_hash.h b/crypto/secure_hash.h
index 491a299a3..a5590e5 100644
--- a/crypto/secure_hash.h
+++ b/crypto/secure_hash.h
@@ -10,11 +10,6 @@
 #include "base/macros.h"
 #include "crypto/crypto_export.h"
 
-namespace base {
-class Pickle;
-class PickleIterator;
-}
-
 namespace crypto {
 
 // A wrapper to calculate secure hashes incrementally, allowing to
@@ -30,17 +25,12 @@ class CRYPTO_EXPORT SecureHash {
 
   virtual void Update(const void* input, size_t len) = 0;
   virtual void Finish(void* output, size_t len) = 0;
+  virtual size_t GetHashLength() const = 0;
 
-  // Serialize the context, so it can be restored at a later time.
-  // |pickle| will contain the serialized data.
-  // Returns whether or not |pickle| was filled.
-  virtual bool Serialize(base::Pickle* pickle) = 0;
-
-  // Restore the context that was saved earlier.
-  // |data_iterator| allows this to be used as part of a larger pickle.
-  // |pickle| holds the saved data.
-  // Returns success or failure.
-  virtual bool Deserialize(base::PickleIterator* data_iterator) = 0;
+  // Create a clone of this SecureHash. The returned clone and this both
+  // represent the same hash state. But from this point on, calling
+  // Update()/Finish() on either doesn't affect the state of the other.
+  virtual SecureHash* Clone() const = 0;
 
  protected:
   SecureHash() {}