Check that the PNaCl cache hash is truly derived from the bitcode content.

ppapi/api/private/ppb_nacl_hash_private.idl

Index: ppapi/api/private/ppb_nacl_hash_private.idl
diff --git a/ppapi/api/private/ppb_nacl_hash_private.idl b/ppapi/api/private/ppb_nacl_hash_private.idl
new file mode 100644
index 0000000000000000000000000000000000000000..57912628f51d4732af39086a3b4dc6bace23460d
--- /dev/null
+++ b/ppapi/api/private/ppb_nacl_hash_private.idl
@@ -0,0 +1,29 @@
+/* Copyright (c) 2013 The Chromium Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+/* This file contains NaCl private interfaces for hashing. This interface
+ * is not versioned and is for internal Chrome use. It may change without
+ * notice. If we convert the NaCl plugin from PPAPI to be renderer code
+ * then we can depend on the chrome hash functions directly.
+ */
+
+/* PPB_NaCl_Hash_Private */
+interface PPB_NaCl_Hash_Private {
+  // Create the hash object for incremental hashing.
+  mem_t CreateSHA256Hash();

[dmichael (off chromium), 2013/05/01 17:22:15]

Should that be "CreateSHA256Hasher" or "...HashObject" or something? Just to
make it clearer it's not returning an actual hash.

[jvoung (off chromium), 2013/05/01 18:23:00]

Done.

+
+  // Update the hash with len more bytes of data.
+  void Update([inout] mem_t hasher, [in] mem_t data, uint32_t len);
+
+  // Finish hashing and get a digest up to len bytes.
+  void Finish([inout] mem_t hasher, [out] mem_t output, [in] uint32_t len);
+
+  // Delete the hash object.
+  void Delete([inout] mem_t hasher);

[dmichael (off chromium), 2013/05/01 17:22:15]

I think it's appropriate to just use [in] for the hasher param in all of these.

[jvoung (off chromium), 2013/05/01 18:23:00]

Hmm, but Update() and Finish() can modify the hasher (the methods aren't const)?

[dmichael (off chromium), 2013/05/01 18:34:15]

But you don't modify the actual |hasher| pointer. It's basically an opaque
handle, much like PP_Resource. In those cases, where the "handle" itself isn't
modified, we just use [in].

[jvoung (off chromium), 2013/05/01 19:18:43]

Do you mean that the pointer won't end up pointing to something else?

I think the issue is that these API files are normally for a C interface where
"const T*" means that the pointer is const, but the implementation and user of
this API is C++ where that syntax means that the pointed-to object is const?

+
+  // Compare two hashes and return PP_TRUE if they are equal.
+  PP_Bool SecureMemEqual([in] str_t hash1, [in] str_t hash2,

[dmichael (off chromium), 2013/05/01 17:22:15]

Any reason you're using str_t and mem_t elsewhere? It seems like mem_t is
equally appropriate here as for Update and Finish.

[jvoung (off chromium), 2013/05/01 18:23:00]

Ah yes, will convert to mem_t.  Originally I had str_t, but changed it since the
original crypto/ headers use void* instead of char*. The original MemEqual also
takes a void*.

+                         [in] uint32_t len);
+};