Support building BoringSSL with NSS certificates.

Initial support for using BoringSSL with NSS certificates.

This switches the USE_OPENSSL Linux and CrOS builds to continue
setting USE_NSS_CERTS. This lets it use BoringSSL for the crypto
and SSL stack and NSS for certificate verification. See design
doc for details on the flags:

https://docs.google.com/document/d/1x4DOCKwFkAxl9MGfd6snIzFigO4ku6Shuci0r5BzasQ/edit

On Linux, only client auth and OCSP stapling are missing. On ChromeOS,
there are some problematic USE_NSS_CERTS APIs in RSAPrivateKey to
resolve. We also still need to resolve crbug.com/347404 to maintain
parity.

As a follow-up, USE_OPENSSL_CERTS on non-Android can now be
removed (it was never supported anyway).

BUG=462040
Committed: https://crrev.com/2bcbc6bceb6017c762ef01553a55a12fe390de16
Cr-Commit-Position: refs/heads/master@{#326222}

[davidben, 2015-01-29 23:59:10]

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

[davidben, 2015-01-29 23:59:11]

Sending out for review, mostly so you can see what it looks like, assuming I've
finally appeased the try bots. Description contains the missing pieces I know
of.

[davidben, 2015-02-12 19:51:30]

Friendly ping. (No rush; just wanted to make sure this was still on the radar.
Curious whether you think this is worth pursuing.)

[Ryan Sleevi, 2015-02-23 20:37:40]

OK, I've read through this CL several times, and I think I've identified the
cause of my brainmelt, and it's the usual one:
You haven't really documented things well

That is, I'm confused about the 'new' interpretations for the GYP flags, which
seem repurposed. You're removing code from some bits (like //crypto), which
suggests you're entirely dropping "use NSS" as a build option, which I think
would be premature. That is, it doesn't seem to permit a build-time
configuration whether to use NSS or to use the frankenbuild.

Today's world of configurations:
- NSS (dynamically linked), with statically linked libssl
  - This is used by Linux/ChromeOS
- NSS (statically linked), with statically linked libssl, without root certs
  - This (was) used by Windows/Mac
- NSS (statically linked), with statically linked libssl, with root certs
  - This _is_ used by iOS
- OpenSSL (statically linked), without using OpenSSL for X.509
  - This is used by Windows/Mac, AIUI
- OpenSSL (statically linked), using OpenSSL for X.509
  - This is used by Android

First, is the above list correct/exhaustive? I'm unclear whether we fully
remvoed from GYP the (old) Windows/Mac configs, but i'd be surprised if we did,
just for rollback sake.

We're now adding
- OpenSSL (statically linked), with NSS (dynamically linked), with no libssl

Right? What's the set of GYP flags to concisely express this new config? Do we
need to omit libssl (I don't think any symbols conflict, but perhaps I'm wrong)?
What if we load a third-party that does link in libssl - does that create issues
[if even possible?]

I think better documenting these sorts of bits, either in the CL description, a
tracking bug, or preferably, within the common.gypi, helps put the rest in
perspective.

Removing the code from //crypto looks a bit shaky though. I'd want to do that in
two phases, I suspect.

https://codereview.chromium.org/881213004/diff/120001/build/linux/system.gyp
File build/linux/system.gyp (right):

https://codereview.chromium.org/881213004/diff/120001/build/linux/system.gyp#...
build/linux/system.gyp:1170: ['use_openssl==0 or use_nss==1', {
I am _deeply_ confused by these GYP variables, between system.gyp and
common.gypi

Could you document more _in the file_ what they mean and how they're set?

[davidben, 2015-02-23 21:31:37]

On 2015/02/23 20:37:40, Ryan Sleevi wrote:
> OK, I've read through this CL several times, and I think I've identified the
> cause of my brainmelt, and it's the usual one:
> You haven't really documented things well
> 
> That is, I'm confused about the 'new' interpretations for the GYP flags, which
> seem repurposed. You're removing code from some bits (like //crypto), which
> suggests you're entirely dropping "use NSS" as a build option, which I think
> would be premature. That is, it doesn't seem to permit a build-time
> configuration whether to use NSS or to use the frankenbuild.

Less new and more clarified really. I think the root cause of the confusion is
that USE_NSS is named wrong based on our current USE_(NSS|OPENSSL) flags. It's
correct in GN, but incorrect in GYP and C preprocessor. Everywhere you see
USE_NSS, do a mental substitution for USE_NSS_CERTS. I was considering renaming
it as a first step. I think we didn't and just started doing it right for GN to
avoid churn, NSS and GYP are supposed to be going away, and it could potentially
confuse downstream builds.

This is the current state of the world, prior to this CL.

SSL and crypto stack flags:
USE_OPENSSL => BoringSSL is used for crypto and SSL implementation. Both are
always bundled.
!USE_OPENSSL => NSS is used for crypto and SSL implementation. SSL
implementation is always bundled. Crypto is sometimes bundled (iOS) sometimes
goes to the system (Linux/CrOS). There is no explicit flag for this and it's
just !USE_OPENSSL.

Platform key and certificate impl flags:
USE_OPENSSL_CERTS => BoringSSL provides the net::X509Certificate representation
and the verifier (X509_verify). XXX: Except when OS_ANDROID is on! This is
weird.
USE_NSS_CERTS => NSS provides the net::X509Certificate representation, verifier,
and client auth bits.
OS_WIN =>Windows APIs provides the net::X509Certificate representation,
verifier, and client auth bits.
OS_MAC => Mac APIs provides the net::X509Certificate representation, verifier,
and client auth bits.
OS_ANDROID =>Android APIs provides the verifier and client auth bits. XXX:
net::X509Certificate representation still comes from USE_OPENSSL_CERTS. This is
weird.
OS_IOS => NSS provides the net::X509Certificate representation and verifier.
XXX: This not setting USE_NSS_CERTS is weird and is why 

In my mind, the first set of config knobs and the second set should be
completely orthogonal. Right now USE_OPENSSL + USE_NSS_CERTS doesn't work
because USE_NSS_CERTS => !USE_OPENSSL. This CL's purpose in life is to fix that.
And this is why the RSAPrivateKey bits are a little confusing. They're for
importing NSS platform keys (so USE_NSS_CERTS), but the APIs assume NSS also
provides our crypto (so !USE_OPENSSL). That's why this doesn't work in CrOS yet.

Later, when we're on BoringSSL for all SSL and crypto, USE_OPENSSL will be
always switched and we can unifdef USE_OPENSSL.

Even later, I'm envisioning that the certificate representation portions of the
second group will go away and be replaced with whatever our new stack's
certificate representation is. That will get rid of the
OS_ANDROID+USE_OPENSSL_CERTS weirdness. Then the first group will control how
Chromium represents its structures. The second group controls platform bits.
Where we need to go between the two (client auth, certificate verifier if we go
out to the platform), we either provide an EVP_PKEY shim or parse the platform
representation from DER.

I'll do a pass so all this is documented in the code and CL description, but...
with that context, do you think I should first do a pass to rename USE_NSS to
USE_NSS_CERTS?

> Today's world of configurations:
> - NSS (dynamically linked), with statically linked libssl
>   - This is used by Linux/ChromeOS
> - NSS (statically linked), with statically linked libssl, without root certs
>   - This (was) used by Windows/Mac
> - NSS (statically linked), with statically linked libssl, with root certs
>   - This _is_ used by iOS
> - OpenSSL (statically linked), without using OpenSSL for X.509
>   - This is used by Windows/Mac, AIUI
> - OpenSSL (statically linked), using OpenSSL for X.509
>   - This is used by Android
> 
> First, is the above list correct/exhaustive? I'm unclear whether we fully
> remvoed from GYP the (old) Windows/Mac configs, but i'd be surprised if we
did,
> just for rollback sake.

I'm not sure there's a whole lot of code that's specific to NSS libssl +
Windows/Mac certs, but yeah I don't think we ever removed that code. Probably
can now.

> We're now adding
> - OpenSSL (statically linked), with NSS (dynamically linked), with no libssl

Correct. But I think separating the crypto and SSL impl from the platform bits
is the clearer framing. (See above.)

> Right? What's the set of GYP flags to concisely express this new config?

USE_OPENSSL + USE_NSS. (Again, apply the USE_NSS -> USE_NSS_CERTS transform.)

> Do we
> need to omit libssl (I don't think any symbols conflict, but perhaps I'm
wrong)?

Our bundled libssl or the system one? The bundled libssl should not be
conditioned on use_nss(_certs), even today, and only on !use_openssl. So we
should not include it. Likewise, we should not be linking the system libssl
because we don't use it. But if we do, I don't think it's harmful, and we do not
have any existing configurations which do this, so I didn't have to change
anything.

> What if we load a third-party that does link in libssl - does that create
issues
> [if even possible?]

I do not believe it will cause issues. I would be more worried about that in our
!use_openssl builds of before. But it would only have caused problems for the
components build because otherwise the symbols aren't exported.

I *would* be worried about loading a third-party that links with system
*OpenSSL*, but that worry is part of switching desktop Linux to BoringSSL at
all, not this chimera. Since it will still only affect the components build, I
think we can just leave it be for now (OpenSSL's GPL incompatibility buffers us
somewhat; desktop Linux doesn't really like using OpenSSL). We don't care if an
exotic smartcard vendor or GTK theme links OpenSSL, only something standard that
hits our bots or developers. Should that happen, we may need to resort to linker
tricks and mangle BoringSSL's symbols or something.

> I think better documenting these sorts of bits, either in the CL description,
a
> tracking bug, or preferably, within the common.gypi, helps put the rest in
> perspective.
> 
> Removing the code from //crypto looks a bit shaky though. I'd want to do that
in
> two phases, I suspect.

Oh. Yeah, that stuff's unused. I can just split it out of this CL... I think it
snuck in here because I thought I'd be able to do something more excited for the
corresponding hooks in RSAPrivateKey but will have to leave that as a TODO.

[davidben, 2015-02-23 21:34:18]

On 2015/02/23 21:31:37, David Benjamin wrote:
> OS_IOS => NSS provides the net::X509Certificate representation and verifier.
> XXX: This not setting USE_NSS_CERTS is weird and is why 

Oops. Never finished this sentence.

XXX: This not setting USE_NSS_CERTS is weird and is why there are iOS-specific
bits in our current build files. I have not attempted to simply this in this CL.

[davidben, 2015-02-24 01:37:47]

On 2015/02/23 21:31:37, David Benjamin wrote:
> I'll do a pass so all this is documented in the code and CL description,
but...
> with that context, do you think I should first do a pass to rename USE_NSS to
> USE_NSS_CERTS?

Unfortunately, there is a downstream consumer that uses USE_NSS. I'm pulling in
a copy of that code to see how pervasive it is, but we'll want to either force
them to update with us, live with the confusion, or provide a temporary USE_NSS
compatibility flag but rename Chromium instances to USE_NSS_CERTS to be less
confusing.

[davidben, 2015-02-25 21:09:39]

Dropped more documentation into the CL and tweaked a few things so they
hopefully make more sense. Also added comments above where USE_NSS and such are
defined in the build files and where particularly strange contortions are
needed. Hopefully this is more understandable.

https://codereview.chromium.org/881213004/diff/160001/crypto/rsa_private_key_...
File crypto/rsa_private_key_nss_unittest.cc (right):

https://codereview.chromium.org/881213004/diff/160001/crypto/rsa_private_key_...
crypto/rsa_private_key_nss_unittest.cc:18: #if !defined(USE_NSS)
This file is really weird because the APIs in question are problematic. I
eventually opted to put the USE_OPENSSL check in the build file and the USE_NSS
check in the source to be consistent with rsa_private_key_nss.cc.

[Ryan Sleevi, 2015-02-26 00:35:35]

Thanks for the documentation - it's helped a lot.

I've taken the first stab, but I'm not gonna lie, my brain started melting at
the build system. I'll take another stab after I've had more coffee, so that I
can carefully review those changes.

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi#newco...
build/common.gypi:73: # Use OpenSSL for representing certificates and, unless
targetting
targeting

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi#newco...
build/common.gypi:74: # Android, the certificate verifier.
s/the certificate verifier/certificate verification/.

https://codereview.chromium.org/881213004/diff/160001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/881213004/diff/160001/crypto/BUILD.gn#newcode326
crypto/BUILD.gn:326: "//net/third_party/nss/ssl:ssl_config",
This doesn't seem right for the use_nss_certs case

[Ryan Sleevi, 2015-02-26 00:35:36]

Thanks for the documentation - it's helped a lot.

I've taken the first stab, but I'm not gonna lie, my brain started melting at
the build system. I'll take another stab after I've had more coffee, so that I
can carefully review those changes.

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi#newco...
build/common.gypi:73: # Use OpenSSL for representing certificates and, unless
targetting
targeting

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi#newco...
build/common.gypi:74: # Android, the certificate verifier.
s/the certificate verifier/certificate verification/.

https://codereview.chromium.org/881213004/diff/160001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/881213004/diff/160001/crypto/BUILD.gn#newcode326
crypto/BUILD.gn:326: "//net/third_party/nss/ssl:ssl_config",
This doesn't seem right for the use_nss_certs case

[davidben, 2015-02-26 22:59:25]

Addressed comments. Also fixed the GN build. All net_unittests are now passing
except for OCSP stapling, which is expected. (I thought I'd done this before,
but evidently not? Maybe something got sad during a rebase.)

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi#newco...
build/common.gypi:73: # Use OpenSSL for representing certificates and, unless
targetting
On 2015/02/26 00:35:35, Ryan Sleevi wrote:
> targeting

Done.

https://codereview.chromium.org/881213004/diff/160001/build/common.gypi#newco...
build/common.gypi:74: # Android, the certificate verifier.
On 2015/02/26 00:35:35, Ryan Sleevi wrote:
> s/the certificate verifier/certificate verification/.

Done.

https://codereview.chromium.org/881213004/diff/160001/crypto/BUILD.gn
File crypto/BUILD.gn (right):

https://codereview.chromium.org/881213004/diff/160001/crypto/BUILD.gn#newcode326
crypto/BUILD.gn:326: "//net/third_party/nss/ssl:ssl_config",
On 2015/02/26 00:35:36, Ryan Sleevi wrote:
> This doesn't seem right for the use_nss_certs case

Yeah, you're right. I've tweaked it a little...

I'm not very happy with how many cases there are in the new version. It's really
much simpler because use_nss_certs = is_linux. But we've historically
conditioned the system vs. bundled bit on NSS with is_linux (even though the
bundled NSS port, iOS, doesn't even set use_nss_certs), so I kept it consistent
with that.

https://codereview.chromium.org/881213004/diff/180001/net/ssl/channel_id_serv...
File net/ssl/channel_id_service.cc (right):

https://codereview.chromium.org/881213004/diff/180001/net/ssl/channel_id_serv...
net/ssl/channel_id_service.cc:249: #if !defined(USE_OPENSSL)
I'm sort of puzzled why this didn't cause problems on our non-USE_NSS NSS
platforms (Windows and Mac previously). As far as I can tell, ChannelID doesn't
interact with the platform crypto library and only the internal one, so I
believe !USE_OPENSSL is correct.

[haavardm, 2015-03-11 14:42:49]

haavardm@opera.com changed reviewers:
+ haavardm@opera.com

[haavardm, 2015-03-11 14:42:51]

A quick drive-by review from me. Our TV browser department is looking forward to
stop using NSS, so this good step forward.

https://codereview.chromium.org/881213004/diff/260001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/881213004/diff/260001/build/common.gypi#newco...
build/common.gypi:659: # reasons, this flag is named use_nss rather than
use_nss_certs. In
Would probably be some work but I mention it anyway: An alternative approach is
to turn on using NSS for cert verification on linux when use_openssl_certs == 0
and remove use_nss completely.

That would be consistent with how !use_openssl turns on using NSS for crypto and
TLS.

https://codereview.chromium.org/881213004/diff/260001/net/cert/x509_util_nss_...
File net/cert/x509_util_nss_certs.cc (right):

https://codereview.chromium.org/881213004/diff/260001/net/cert/x509_util_nss_...
net/cert/x509_util_nss_certs.cc:29: #include "net/cert/x509_util_nss.h"
Shouldn't this be moved to top?

https://codereview.chromium.org/881213004/diff/260001/net/net.gyp
File net/net.gyp (right):

https://codereview.chromium.org/881213004/diff/260001/net/net.gyp#newcode584
net/net.gyp:584: }, {  # use_openssl == 0
For shared library builds, like you did on line 269 you must add the condition
'use_nss == 1 or OS == "ios" or use_openssl == 0'  instead of an 'else'.

[davidben, 2015-03-11 23:32:42]

https://codereview.chromium.org/881213004/diff/260001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/881213004/diff/260001/build/common.gypi#newco...
build/common.gypi:659: # reasons, this flag is named use_nss rather than
use_nss_certs. In
On 2015/03/11 14:42:50, haavardm wrote:
> Would probably be some work but I mention it anyway: An alternative approach
is
> to turn on using NSS for cert verification on linux when use_openssl_certs ==
0
> and remove use_nss completely.
> 
> That would be consistent with how !use_openssl turns on using NSS for crypto
and
> TLS.

Hrm. So we can't easily get rid of USE_NSS the preprocessor flag. I don't have
terribly strong opinions about getting rid of use_nss(_certs) the build flag.
It'd probably make a lot of the conditions messier? Probably not worth all the
churn if NSS is going away.

Really, it doesn't make any sense to keep the USE_OPENSSL_CERTS flag on Linux
anyway. We should probably just drop it and fold it into OS_ANDROID in a
follow-up. That configuration is unsupported and not likely to ever become
supported; we won't be using X509_verify post-NSS, and I'd like to unify the
net::X509Certificate in-memory representation away from OpenSSL's crypto/x509
stack and to the new PKI stack. Both crypto/x509 and crypto/asn1 are
sufficiently decrepit that we're intentionally not touching them in BoringSSL.
We'll migrate away from them altogether.

https://codereview.chromium.org/881213004/diff/260001/net/cert/x509_util_nss_...
File net/cert/x509_util_nss_certs.cc (right):

https://codereview.chromium.org/881213004/diff/260001/net/cert/x509_util_nss_...
net/cert/x509_util_nss_certs.cc:29: #include "net/cert/x509_util_nss.h"
On 2015/03/11 14:42:51, haavardm wrote:
> Shouldn't this be moved to top?

The include order checker doesn't accept _certs.cc as a suffix for candidacy for
moving to the top. (We could split the header in two instead. I haven't bothered
for now.)

Another option is probably to keep the files as one and instead use #ifdefs.

https://codereview.chromium.org/881213004/diff/260001/net/net.gyp
File net/net.gyp (right):

https://codereview.chromium.org/881213004/diff/260001/net/net.gyp#newcode584
net/net.gyp:584: }, {  # use_openssl == 0
On 2015/03/11 14:42:51, haavardm wrote:
> For shared library builds, like you did on line 269 you must add the condition
> 'use_nss == 1 or OS == "ios" or use_openssl == 0'  instead of an 'else'.

Done. I suspect this is redundant with a bunch of stuff through.

(Actually that file exclusion for the unit tests is wrong anyway... fixing those
up too)

[Ryan Sleevi, 2015-04-20 11:06:17]

LGTM. Sorry for the many delays.

One request I have is that there's a lot of TODOs tied to the meta-bug - to make
sure we don't miss those, can you break those into smaller, concrete bugs, and
mark them as blocking of the overall bug? That will help make sure we clean up
all the transitional TODOs.

https://codereview.chromium.org/881213004/diff/180001/net/ssl/channel_id_serv...
File net/ssl/channel_id_service.cc (right):

https://codereview.chromium.org/881213004/diff/180001/net/ssl/channel_id_serv...
net/ssl/channel_id_service.cc:249: #if !defined(USE_OPENSSL)
On 2015/02/26 22:59:25, David Benjamin wrote:
> I'm sort of puzzled why this didn't cause problems on our non-USE_NSS NSS
> platforms (Windows and Mac previously). As far as I can tell, ChannelID
doesn't
> interact with the platform crypto library and only the internal one, so I
> believe !USE_OPENSSL is correct.

because we suppress the leaks in our sanitizers ;)

[davidben, 2015-04-21 02:34:26]

On 2015/04/20 11:06:17, Ryan Sleevi wrote:
> LGTM. Sorry for the many delays.
> 
> One request I have is that there's a lot of TODOs tied to the meta-bug - to
make
> sure we don't miss those, can you break those into smaller, concrete bugs, and
> mark them as blocking of the overall bug? That will help make sure we clean up
> all the transitional TODOs.

Done. Will CQ once try jobs clear.

[davidben, 2015-04-21 16:04:27]

The CQ bit was checked by davidben@chromium.org

[davidben, 2015-04-21 16:04:28]

The patchset sent to the CQ was uploaded after l-g-t-m from rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/881213004/#ps400001
(title: "staple bugs to TODOs")

[commit-bot: I haz the power, 2015-04-21 16:05:07]

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

[commit-bot: I haz the power, 2015-04-21 16:15:27]

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

[commit-bot: I haz the power, 2015-04-21 16:15:28]

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

[davidben, 2015-04-21 17:53:31]

davidben@chromium.org changed reviewers:
+ isherman@chromium.org, sky@chromium.org, thakis@chromium.org

[davidben, 2015-04-21 17:53:32]

+thakis for build/OWNERS
+isherman for chrome/utility/importer/
+sky for chrome/utility/BUILD.gn

[tfarina, 2015-04-21 21:49:19]

https://codereview.chromium.org/881213004/diff/400001/chrome/utility/BUILD.gn
File chrome/utility/BUILD.gn (right):

https://codereview.chromium.org/881213004/diff/400001/chrome/utility/BUILD.gn...
chrome/utility/BUILD.gn:86: if (use_nss_certs) {
non-owner lgtm for this GN change.

Though with one question. Why don't you need to exclude nss_decryptor.cc
anymore?

[Ilya Sherman, 2015-04-21 22:03:09]

importer lgtm

[davidben, 2015-04-21 22:16:06]

https://codereview.chromium.org/881213004/diff/400001/chrome/utility/BUILD.gn
File chrome/utility/BUILD.gn (right):

https://codereview.chromium.org/881213004/diff/400001/chrome/utility/BUILD.gn...
chrome/utility/BUILD.gn:86: if (use_nss_certs) {
On 2015/04/21 21:49:19, tfarina wrote:
> non-owner lgtm for this GN change.
> 
> Though with one question. Why don't you need to exclude nss_decryptor.cc
> anymore?

use_openssl && !is_win && !is_mac_ && !is_android was never true. Those are
precisely the three platforms where we've shipped use_openssl.

That logic was there so that Linux + use_openssl could continue to build,
despite nss_decryptor not actually working. It's paired with
nss_decryptor_null.h which instead defines those functions to be no-ops (whereas
the real NSSDecryptor implementations use nss_decryptor.cc as common code).

This was used because that port used not link with NSS at all and instead use
OpenSSL's X509_verify, a configuration we do not and don't intend to support. It
was mostly used as development convenience in building OpenSSL versions on
Linux.

Now Linux + use_openssl still pulls in NSS, so we can continue to use the old
code and transition off of it incrementally. (When we do manage to ship a
non-use_nss_certs Linux build, we'll need some kind of story for this, either
continue to link with system NSS or perhaps dlopen Firefox's copy like we do on
Mac and Windows.)

On that note, I forgot to remove nss_decryptor_null.h. Fixed.

[davidben, 2015-04-21 22:17:24]

davidben@chromium.org changed reviewers:
+ dpranke@chromium.org
- thakis@chromium.org

[davidben, 2015-04-21 22:17:25]

Swapping in dpranke for thakis for build/OWNERS since thakis is OOO sick.

[Dirk Pranke, 2015-04-21 22:34:02]

lgtm

[sky, 2015-04-21 23:45:40]

LGTM

[davidben, 2015-04-22 00:53:15]

The CQ bit was checked by davidben@chromium.org

[davidben, 2015-04-22 00:53:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
rsleevi@chromium.org, tfarina@chromium.org, isherman@chromium.org,
dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/881213004/#ps440001
(title: "rebase")

[commit-bot: I haz the power, 2015-04-22 00:53:54]

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

[commit-bot: I haz the power, 2015-04-22 02:36:50]

Committed patchset #23 (id:440001)

[commit-bot: I haz the power, 2015-04-22 02:37:52]

Patchset 23 (id:??) landed as
https://crrev.com/2bcbc6bceb6017c762ef01553a55a12fe390de16
Cr-Commit-Position: refs/heads/master@{#326222}