Pickle (serialize and deserialize) MultiThreadedCertVerifier's |cache_|

net/cert/cert_verify_result.h

Index: net/cert/cert_verify_result.h
diff --git a/net/cert/cert_verify_result.h b/net/cert/cert_verify_result.h
index 1cfb8fa51b3aa3655905cdc1f6e9a3292b9e07a7..0160ba7dae833b272c8481fb202ddb8ad052c4df 100644
--- a/net/cert/cert_verify_result.h
+++ b/net/cert/cert_verify_result.h
@@ -8,6 +8,7 @@
 #include <vector>
 
 #include "base/memory/ref_counted.h"
+#include "base/pickle.h"
 #include "net/base/net_export.h"
 #include "net/cert/cert_status_flags.h"
 #include "net/cert/x509_cert_types.h"
@@ -23,6 +24,16 @@ class NET_EXPORT CertVerifyResult {
   CertVerifyResult(const CertVerifyResult& other);
   ~CertVerifyResult();
 
+  // Appends a representation of this object to the given pickle.
+  bool Persist(base::Pickle* pickle) const;
+
+  // Create an CertVerifyResult from the representation stored in the given
+  // pickle. The data for this object is found relative to the given
+  // pickle_iter, which should be passed to the pickle's various Read* methods.
+  // Returns false on failure.
+  static bool CreateFromPickle(base::PickleIterator* iter,
+                               CertVerifyResult* result);

[Ryan Sleevi, 2016/02/29 23:28:41]

I'm strongly opposed to adding pickling methods

1) Security: This is touched upon in
https://www.chromium.org/Home/chromium-security/education/security-tips-for-i....
, but in general, serialization logic like this is subtle, complex, and a rife
opportunity for security bugs.

2) Design: This violates the "Single Responsibility" into adding complex
serialization logic here

3) API DESIGN: This is meant to be an internal type, not a file-stable type.
Adding serialization to this type means complex versioning schemes must
inevitably be dealt with - and we should not encourage that. This is why we have
things like Protobufs, to handle when fields are present or not, rather than
creating ad-hoc serialization schemes.

+
   void Reset();
 
   // Copies from |other| to |this|.