Make transport security state data source configurable.

net/http/transport_security_state_structs.h

Index: net/http/transport_security_state_structs.h
diff --git a/net/http/transport_security_state_structs.h b/net/http/transport_security_state_structs.h
new file mode 100644
index 0000000000000000000000000000000000000000..40a90798311408d7554bbd1185246a46c228d4a4
--- /dev/null
+++ b/net/http/transport_security_state_structs.h
@@ -0,0 +1,30 @@
+// Copyright (c) 2017 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.
+
+#ifndef NET_HTTP_TRANSPORT_SECURITY_STATE_STRUCTS_H_

[Ryan Sleevi, 2017/03/13 18:31:18]

So we generally try to avoid naming 'catchall cloaca' files ;)

Does this make sense as TransportSecurityStateSource, of which Pinset is an
implementation detail of a TSSSource? 

[martijnc, 2017/03/13 21:51:40]

Not really sure what you mean but I'be made Pinset part of
TransportSecurityStateSource although it's not really an implementation detail
now. It's still exposed because it is needed in other places.

[Ryan Sleevi, 2017/03/13 21:59:40]

Well, mostly because "_structs" is a catchall, like _util or _misc. It doesn't
really provide clear guidance as to what it contains (if reading the header) or
what it should contain (if considering additions). As a consequence, it often
becomes a catchall for a variety of decisions, rather than trying to think
through the design.

I set "an implementation detail" mostly because the only way you get a Pinset is
in conjunction with a TransportSecurityStateSource - right?

Not that I'm suggesting this level of class design (there's pros and cons), but
I'm curious from an API direction if

struct TransportSecurityStateSource {
  struct Pinset {

  };

  ...
  const struct Pinset* pinsets;
};

is conceptually equivalent?

(If it's answered already in the 'master' CL, feel free to just link there
directly and I can read/see its usage)

[martijnc, 2017/03/13 22:47:58]

Ah, I was a bit confused by what you meant by "implementation detail", but yes,
a Pinset always comes as part of a TransportSecurityStateSource. If there is a
Pinset, it is part of some TransportSecurityStateSource so making Pinset an
implementation detail of TransportSecurityStateSource makes sense (and signals
this relationship in the code better).

+#define NET_HTTP_TRANSPORT_SECURITY_STATE_STRUCTS_H_
+
+namespace net {
+
+struct Pinset {
+  const char* const* const accepted_pins;
+  const char* const* const rejected_pins;
+  const char* const report_uri;
+};
+
+struct TransportSecurityStateSource {
+  const uint8_t* huffman_tree;
+  size_t huffman_tree_size;
+  const uint8_t* preloaded_data;
+  size_t preloaded_bits;
+  size_t root_position;
+  const char* const* expect_ct_report_uris;
+  const char* const* expect_staple_report_uris;
+  const struct Pinset* pinsets;

[Ryan Sleevi, 2017/03/13 21:59:40]

No need to "struct pinset" this, since you define it on line 10-14

[martijnc, 2017/03/13 22:47:58]

Done.

+  size_t pinsets_count;
+};
+
+}  // namespace net
+
+#endif  // NET_HTTP_TRANSPORT_SECURITY_STATE_STRUCTS_H_