Currently we use a script called transport_security_state_static_generate.go convert preload list from JSON [1] into a header file [2].
There are two important parts:
1) Convert the data into a Huffman tree.
2) Parse SPKIs from source data (certs and public keys) [3] to produce hashes.
I'd like to include at least #1 in the build process.
#2 is slower and more complicated, but the preloaded SPKIs change less than once per Chrome version on average – we can manually update a list of hashes in each CL (e.g. by including the hashes in the .certs file directly).
Benefits:
a) Easy to merge and cherry-pick changes onto different branches.
b) Allows sending logically separate changes (e.g. separated removals and additions) to the commit queue at the same time.
- This allows the preload list maintainer to handle unrelated additions, changes, and removals in “one sitting” without having to create a unified CL or dependent CLs.
c) This avoids large CLs. Each preload list update currently takes up 500KB permanently on each developer's machine.
In fact, c) is now my biggest concern. I didn't think about this until I hit the default CL patch limit for per-file diffs [4], but I am trying to reduce the number of HSTS preload list changes until we can make sure that preload list updates don't result in large updates to the source code.
[1] https://github.com/agl/transport-security-state-generate
[2] https://chromium.googlesource.com/chromium/src/+blame/master/net/http/transport_security_state_static.json
[3] https://chromium.googlesource.com/chromium/src/+blame/master/net/http/transport_security_state_static.certs
[4] https://codereview.chromium.org/1765083003#msg9
Comment 1 by lgar...@chromium.org
, Jun 7 2016