Require a CTVerifier and CTPolicyEnforcer for TLS/QUIC sockets

Require a CTVerifier and CTPolicyEnforcer for TLS/QUIC sockets

In order to determine the trustworthiness of the connection, it's
necessary for sockets to consider policies regarding CT - both what
logs to trust and what policies to enforce. As this is critical to
security, make CTVerifier* and CTPolicyEnforcer* necessary, rather
than optional, for sockets. For normal URLRequestContexts, this
should be a no-op, while for those created via the
URLReqestContextBuilder, sane defaults will be provided.

BUG=620179
Committed: https://crrev.com/d6de830088694ffab3218b77fa070084e88160ac
Cr-Commit-Position: refs/heads/master@{#400870}

[Ryan Sleevi, 2016-06-15 01:00:53]

rch: In advance of our discussions tomorrow.

[Ryan Sleevi, 2016-06-15 01:00:58]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-15 01:01:17]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/1

[commit-bot: I haz the power, 2016-06-15 01:05:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-15 01:05:05]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_clobber_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[Ryan Sleevi, 2016-06-15 01:12:18]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-15 01:12:31]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/20001

[Ryan Sleevi, 2016-06-15 01:25:05]

https://codereview.chromium.org/2067843003/diff/1/net/spdy/spdy_test_util_com...
File net/spdy/spdy_test_util_common.cc (left):

https://codereview.chromium.org/2067843003/diff/1/net/spdy/spdy_test_util_com...
net/spdy/spdy_test_util_common.cc:367:
host_resolver->set_synchronous_mode(true);
Interestingly, this *wasn't* set if you supplied a proxy explicitly, which
caused other tests to behave non-deterministically. "WTF"

[commit-bot: I haz the power, 2016-06-15 01:37:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-15 01:37:11]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Ryan Sleevi, 2016-06-15 02:28:45]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-15 02:28:55]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/40001

[commit-bot: I haz the power, 2016-06-15 02:51:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-15 02:51:45]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Ryan Sleevi, 2016-06-15 03:16:13]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-15 03:16:27]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/70001

[Ryan Sleevi, 2016-06-15 03:44:35]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-15 03:44:51]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/110001

[commit-bot: I haz the power, 2016-06-15 04:22:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-15 04:22:06]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Ryan Sleevi, 2016-06-15 21:56:53]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-15 21:57:42]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/130001

[commit-bot: I haz the power, 2016-06-15 23:16:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-15 23:16:16]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ryan Sleevi, 2016-06-16 00:20:32]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-16 00:20:51]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/170001

[Ryan Sleevi, 2016-06-16 01:58:20]

rsleevi@chromium.org changed reviewers:
+ mmenke@chromium.org, rch@chromium.org

[Ryan Sleevi, 2016-06-16 01:58:21]

Matt: Could you take a look at this from the IOThread/URLRequestContext side of
things?

Ryan: Could you focus on the //net changes, in particular the HTTP changes?


Ryan and I met to discuss the QUIC side, and I waffled back and forth whether or
not to move the DCHECK from the ProofVerifierChromium (which means it triggers
every time you create an HttpNetworkSession if you didn't supply it) to the
ProofVerifierChromium::Job (which means it only triggers when you connect, which
is symmetric with the SSLClientSocket change). I've gone circles around what
option is better, Ryan was 50% meh and 25% on either way, so if you have strong
feelings Matt, happy to change the approach (which means less changes)

I'm handwaving-away the fact that MultiLogCTVerifier, as constructed in all of
this, "Does Nothing" (because it doesn't add the baked in logs). To me, that's a
separable issue to be resolved, but doesn't change the substance of this here
(although it may means a future cleanup to be CTVerifier::CreateDefault()....
note, part of the abstraction and interface choice is so we can support two
wire-incompatible versions of CT and normalize the outputs, which is why the
abstraction in the first-place).

Wanted to get initial review before I OWNERS hunt.

[Ryan Sleevi, 2016-06-16 02:06:33]

On 2016/06/16 01:58:21, Ryan Sleevi wrote:
> Wanted to get initial review before I OWNERS hunt.

Also, I've been torn on how much cleanup to do now (as this has some time
sensitivity, because it blocks requiring CT for Symantec). The whole "Setup an
HttpNetworkSession::Params from a URLRequestContext" just feels all sorts of
wrong. It feels like everyone doing it should be using URLRequestContextBuilder
and then, and only then, overriding the params as they feel appropriate.

So this is like, //content/shell/browser/shell_url_request_context_getter.cc,
//ios/web/shell/, //net/proxy/proxy_script_fetcher_impl_unittest,
//net/url_request/url_request_test_util

I'm also ignoring the obvious and glaring "ct_policy_enforcer" vs
"cert_transparency_verifier" asymmetry. That ship has sailed and pre-dates this
CL (although I was the one who approved the CL introducing the asymmetry), and
is in need of a good mass-fixing (whether that is to ct_verifier and
ct_policy_enforcer or to the other direction, I'm not sure, but //net/cert is
pretty heavy on "CT" being an abbreviation now, so I lean towards that)

[commit-bot: I haz the power, 2016-06-16 02:15:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-16 02:15:20]

Dry run: Try jobs failed on following builders:
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[mmenke, 2016-06-16 02:25:47]

On 2016/06/16 02:06:33, Ryan Sleevi wrote:
> On 2016/06/16 01:58:21, Ryan Sleevi wrote:
> > Wanted to get initial review before I OWNERS hunt.
> 
> Also, I've been torn on how much cleanup to do now (as this has some time
> sensitivity, because it blocks requiring CT for Symantec). The whole "Setup an
> HttpNetworkSession::Params from a URLRequestContext" just feels all sorts of
> wrong. It feels like everyone doing it should be using
URLRequestContextBuilder
> and then, and only then, overriding the params as they feel appropriate.
> 
> So this is like, //content/shell/browser/shell_url_request_context_getter.cc,
> //ios/web/shell/, //net/proxy/proxy_script_fetcher_impl_unittest,
> //net/url_request/url_request_test_util

Note that having net/proxy use it does introduce a circular dependency, at the
directory level (net/proxy tests depend on net/url_request depends on net/http
depends on net/proxy).  I think it's the better approach, but we could end up
making tools just to create an HttpNetworkSession instead.

> I'm also ignoring the obvious and glaring "ct_policy_enforcer" vs
> "cert_transparency_verifier" asymmetry. That ship has sailed and pre-dates
this
> CL (although I was the one who approved the CL introducing the asymmetry), and
> is in need of a good mass-fixing (whether that is to ct_verifier and
> ct_policy_enforcer or to the other direction, I'm not sure, but //net/cert is
> pretty heavy on "CT" being an abbreviation now, so I lean towards that)

As someone who doesn't work on anything cert-related, I actually don't have
strong feelings here, though I do think if you go with CT, all externally
consumed classes (accessed directly by something that doesn't have "ct" in its
name) should have "Certificate Transparency" in the first line of the class
description, if you go with "ct".

[Ryan Hamilton, 2016-06-16 03:31:05]

net/ LGTM modulo a few minor nits (not all of which you need to touch :>)

This makes me wonder.... Should we have a DCHECK in
HttpNetworkSession::HttpNetworkSession()?

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_network_...
File net/http/http_network_session.cc (right):

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_network_...
net/http/http_network_session.cc:81: ct_policy_enforcer(NULL),
nullptr as long as you're here?

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_network_...
File net/http/http_network_session.h (right):

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_network_...
net/http/http_network_session.h:75: CTPolicyEnforcer* ct_policy_enforcer;
Yeah, this asymmetry is glaring when you move these together :>

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_stream_f...
File net/http/http_stream_factory_impl_unittest.cc (right):

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_stream_f...
net/http/http_stream_factory_impl_unittest.cc:468: ct_policy_enforcer,         
// ct_policy_enforcer
no reason for the comments on the non-literals but whatever. not your yak unless
you want it to be

https://codereview.chromium.org/2067843003/diff/170001/net/quic/crypto/proof_...
File net/quic/crypto/proof_verifier_chromium_test.cc (left):

https://codereview.chromium.org/2067843003/diff/170001/net/quic/crypto/proof_...
net/quic/crypto/proof_verifier_chromium_test.cc:281:
TEST_F(ProofVerifierChromiumTest, PreservesEVIfNoPolicy) {
Yay! :>

https://codereview.chromium.org/2067843003/diff/170001/net/socket/ssl_client_...
File net/socket/ssl_client_socket.h (right):

https://codereview.chromium.org/2067843003/diff/170001/net/socket/ssl_client_...
net/socket/ssl_client_socket.h:44: SSLClientSocketContext() = default;
Do you need this at all now?

https://codereview.chromium.org/2067843003/diff/170001/net/spdy/spdy_test_uti...
File net/spdy/spdy_test_util_common.h (right):

https://codereview.chromium.org/2067843003/diff/170001/net/spdy/spdy_test_uti...
net/spdy/spdy_test_util_common.h:195: std::unique_ptr<CTVerifier>
cert_transparency_verifier;
s/cert_/ct_/?

*shrug*

https://codereview.chromium.org/2067843003/diff/170001/net/url_request/url_re...
File net/url_request/url_request_test_util.cc (right):

https://codereview.chromium.org/2067843003/diff/170001/net/url_request/url_re...
net/url_request/url_request_test_util.cc:85: base::WrapUnique(new
MultiLogCTVerifier()));
Since the if body is more than one line, should these have {}s (Like on line
91... but unlike the others? *boggle*

[Ryan Sleevi, 2016-06-16 21:29:17]

Why a DCHECK in HttpNetworkSession? Seems like it's a policy choice of the
implementing classes, where the DCHECKs currently live.

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_network_...
File net/http/http_network_session.cc (right):

https://codereview.chromium.org/2067843003/diff/170001/net/http/http_network_...
net/http/http_network_session.cc:81: ct_policy_enforcer(NULL),
On 2016/06/16 03:31:04, Ryan Hamilton wrote:
> nullptr as long as you're here?

Opted not to. File consistency should reign here - and changing this file t use
nullptr entirely is outside the scope of this CL.

https://codereview.chromium.org/2067843003/diff/170001/net/socket/ssl_client_...
File net/socket/ssl_client_socket.h (right):

https://codereview.chromium.org/2067843003/diff/170001/net/socket/ssl_client_...
net/socket/ssl_client_socket.h:44: SSLClientSocketContext() = default;
On 2016/06/16 03:31:04, Ryan Hamilton wrote:
> Do you need this at all now?

Yes. Omitting it, but leaving line 45 in place, means that the compiler will not
implicitly generate this constructor, because one is already defined. This makes
it possible to still specify an (empty) SSLClientSocketContext.

[Ryan Hamilton, 2016-06-16 23:31:49]

Still LGTM while I bikeshed :>

On 2016/06/16 21:29:17, Ryan Sleevi wrote:
> Why a DCHECK in HttpNetworkSession? Seems like it's a policy choice of the
> implementing classes, where the DCHECKs currently live.

Because if you try to create an HttpNetworkSession w/o one it'll DCHECK?

[mmenke, 2016-06-17 20:01:44]

LGTM - forgot to get to this yesterday.

https://codereview.chromium.org/2067843003/diff/190001/chrome/browser/profile...
File chrome/browser/profiles/profile_io_data.cc (right):

https://codereview.chromium.org/2067843003/diff/190001/chrome/browser/profile...
chrome/browser/profiles/profile_io_data.cc:86: #include
"net/cert/ct_policy_enforcer.h"
Not needed?

[Ryan Sleevi, 2016-06-17 21:22:40]

rsleevi@chromium.org changed reviewers:
+ eugenebut@chromium.org, nasko@chromium.org, rockot@chromium.org,
rogerta@chromium.org, sergeyu@chromium.org

[Ryan Sleevi, 2016-06-17 21:22:41]

nasko: content/
sergeyu: remoting/ and jingle/
rogerta: google_apis/
rockot: extensions/
eugenebut: ios/

[Ryan Sleevi, 2016-06-17 21:23:15]

rsleevi@chromium.org changed reviewers:
+ slan@chromium.org

[Ryan Sleevi, 2016-06-17 21:23:16]

oh, and slan@ for chromecast

[Sergey Ulanov, 2016-06-17 21:25:20]

remoting and jingle LGTM

[Eugene But (OOO till 7-30), 2016-06-17 21:31:20]

ios lgtm

[Ken Rockot(use gerrit already), 2016-06-17 21:39:32]

lgtm

[Ryan Sleevi, 2016-06-17 21:43:32]

rsleevi@chromium.org changed reviewers:
+ jochen@chromium.org
- nasko@chromium.org

[Ryan Sleevi, 2016-06-17 21:43:33]

Nasko changed his status to OOO, so jochen for content/

[slan, 2016-06-17 22:17:04]

cast lgtm

[Eran Messeri, 2016-06-20 09:32:00]

eranm@chromium.org changed reviewers:
+ eranm@chromium.org

[Eran Messeri, 2016-06-20 09:32:02]

lgtm, pleased to see this change happen.
I'll just note that in some contexts a new MultiLogCTVerifier is created, if
logs are not added then no certificate will adhere to the CT policy. May not be
important in these contexts, but worth keeping in mind.

https://codereview.chromium.org/2067843003/diff/210001/content/browser/render...
File content/browser/renderer_host/pepper/ssl_context_helper.cc (right):

https://codereview.chromium.org/2067843003/diff/210001/content/browser/render...
content/browser/renderer_host/pepper/ssl_context_helper.cc:32:
cert_transparency_verifier_.reset(new net::MultiLogCTVerifier());
I'll note that AddLogs with the known logs is never called here so the created
cert_transparency_verifier_ will always say all SCTs are from unknown logs.

[jochen (gone - plz use gerrit), 2016-06-20 09:54:58]

lgtm

[Roger Tawa OOO till Jul 10th, 2016-06-20 14:06:53]

google_apis lgtm

[Ryan Sleevi, 2016-06-20 16:27:27]

https://codereview.chromium.org/2067843003/diff/210001/content/browser/render...
File content/browser/renderer_host/pepper/ssl_context_helper.cc (right):

https://codereview.chromium.org/2067843003/diff/210001/content/browser/render...
content/browser/renderer_host/pepper/ssl_context_helper.cc:32:
cert_transparency_verifier_.reset(new net::MultiLogCTVerifier());
On 2016/06/20 09:32:02, Eran Messeri wrote:
> I'll note that AddLogs with the known logs is never called here so the created
> cert_transparency_verifier_ will always say all SCTs are from unknown logs.

Yes. This is all intentional. There are a number of cleanups needed around the
handling of CT, but the behaviour of this CL still behaves correctly. That is,
it doesn't validate any CT information (a simple 'pass through' implementation)
for these platforms.

[Ryan Sleevi, 2016-06-20 21:25:41]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-06-20 21:25:41]

The patchset sent to the CQ was uploaded after l-g-t-m from rch@chromium.org,
mmenke@chromium.org, rockot@chromium.org, jochen@chromium.org,
eranm@chromium.org, slan@chromium.org, sergeyu@chromium.org,
eugenebut@chromium.org, rogerta@chromium.org
Link to the patchset: https://codereview.chromium.org/2067843003/#ps230001
(title: "Rebased")

[commit-bot: I haz the power, 2016-06-20 21:26:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/230001

[commit-bot: I haz the power, 2016-06-20 21:38:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-20 21:38:51]

Try jobs failed on following builders:
  ios-simulator-gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[Ryan Sleevi, 2016-06-20 21:45:18]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-06-20 21:45:19]

The patchset sent to the CQ was uploaded after l-g-t-m from rockot@chromium.org,
jochen@chromium.org, eranm@chromium.org, slan@chromium.org,
sergeyu@chromium.org, eugenebut@chromium.org, rch@chromium.org,
rogerta@chromium.org, mmenke@chromium.org
Link to the patchset: https://codereview.chromium.org/2067843003/#ps250001
(title: "Bad rebase")

[commit-bot: I haz the power, 2016-06-20 21:45:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/250001

[commit-bot: I haz the power, 2016-06-20 22:09:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-20 22:09:39]

Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ryan Sleevi, 2016-06-21 00:20:29]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-21 00:20:51]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/270001

[commit-bot: I haz the power, 2016-06-21 01:23:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-21 01:23:21]

Dry run: This issue passed the CQ dry run.

[Ryan Sleevi, 2016-06-21 01:26:14]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-06-21 01:26:15]

The patchset sent to the CQ was uploaded after l-g-t-m from rockot@chromium.org,
jochen@chromium.org, eranm@chromium.org, slan@chromium.org,
sergeyu@chromium.org, eugenebut@chromium.org, rch@chromium.org,
rogerta@chromium.org, mmenke@chromium.org
Link to the patchset: https://codereview.chromium.org/2067843003/#ps270001
(title: "Fixup")

[commit-bot: I haz the power, 2016-06-21 01:26:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2067843003/270001

[commit-bot: I haz the power, 2016-06-21 01:33:39]

Committed patchset #15 (id:270001)

[commit-bot: I haz the power, 2016-06-21 01:37:52]

Description was changed from

==========
Require a CTVerifier and CTPolicyEnforcer for TLS/QUIC sockets

In order to determine the trustworthiness of the connection, it's
necessary for sockets to consider policies regarding CT - both what
logs to trust and what policies to enforce. As this is critical to
security, make CTVerifier* and CTPolicyEnforcer* necessary, rather
than optional, for sockets. For normal URLRequestContexts, this
should be a no-op, while for those created via the
URLReqestContextBuilder, sane defaults will be provided.

BUG=620179
==========

to

==========
Require a CTVerifier and CTPolicyEnforcer for TLS/QUIC sockets

In order to determine the trustworthiness of the connection, it's
necessary for sockets to consider policies regarding CT - both what
logs to trust and what policies to enforce. As this is critical to
security, make CTVerifier* and CTPolicyEnforcer* necessary, rather
than optional, for sockets. For normal URLRequestContexts, this
should be a no-op, while for those created via the
URLReqestContextBuilder, sane defaults will be provided.

BUG=620179

Committed: https://crrev.com/d6de830088694ffab3218b77fa070084e88160ac
Cr-Commit-Position: refs/heads/master@{#400870}
==========

[commit-bot: I haz the power, 2016-06-21 01:37:54]

Patchset 15 (id:??) landed as
https://crrev.com/d6de830088694ffab3218b77fa070084e88160ac
Cr-Commit-Position: refs/heads/master@{#400870}