Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
8374020:
Make it a fatal SSL error when encountering certs signed with md[2,4], and interstitial md5 (Closed)
|
Created:
9 years, 2 months ago by Ryan Sleevi Modified:
9 years ago CC:
chromium-reviews, joi+watch-content_chromium.org, darin-cc_chromium.org, cbentzel+watch_chromium.org, jam, dpranke-watch+content_chromium.org, agl, ian fette, Chris Evans Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionWhen encountering certificates signed with md2/md4, make it a fatal error.
When encountering certificates signed with md5, interstitial the page with an error about md5 being a weak signing algorithm.
This excludes checking the signatures of root certificates (trust anchors), as their self-signed signatures are not relevant to the security of the chain.
R=wtc@chromium.org
BUG=101123
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=114432
Patch Set 1 #
Total comments: 6
Patch Set 2 : Rebased #Patch Set 3 : MD2 & MD4: INVALID, MD5: WEAK #
Total comments: 4
Patch Set 4 : joth feedback #
Total comments: 3
Patch Set 5 : Rebase #Patch Set 6 : Feedback and address the major error masking #Patch Set 7 : Fix extra newline #Patch Set 8 : Add extra check #
Total comments: 8
Patch Set 9 : Rebase before commit #Patch Set 10 : wtc feedback #
Messages
Total messages: 33 (0 generated)
wtc: For your review joth: The one _openssl change to make it treat an invalid usage the same as Win/Mac/NSS do palmer: FYI This makes MD5 fatal (non-recoverable), which seemed the direction palmer preferred. I'm fine making MD5 interstitialed and just MD2/MD4 disabled, but given user's click-through on interstitials, and palmer's numbers, it seemed acceptable to just disable. Does ifette need to be cc'd on this (as other crypto-policy decisions seem to have been?) Note: Unittest is forthcoming - I just need to whip up some new md2/md4/md5 test certificates by hand.
http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate.cc#ne... net/base/x509_certificate.cc:607: verify_result->has_md5) { wtc does not want to ban MD5 yet. To ban MD5, and we ultimately must, we will want to collaborate with other browser vendors and CA/B Forum. For now, let's only ban MD2 and MD5. NOTE that we MUST NOT ban the 4 known Verisign MD2-signed root certs. (I don't know if this code applies to roots, or just end entities and intermediaries?) We could conceivably ban MD2 (and MD4) also for roots but special-case the 4 known MD2 root certs. That would be the tightest solution, if feasible.
Review comments on Patch Set 1: rsleevi: thanks for writing the patch quickly! I have two suggestions below (the first suggested change is optional). http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate_opens... File net/base/x509_certificate_openssl.cc (right): http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate_opens... net/base/x509_certificate_openssl.cc:183: case X509_V_ERR_KEYUSAGE_NO_CERTSIGN: The change in this file is correct, regardless of the rest of the CL. You may check in this change first. http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate_win.cc File net/base/x509_certificate_win.cc (left): http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate_win.c... net/base/x509_certificate_win.cc:808: verify_result->cert_status |= CERT_STATUS_WEAK_SIGNATURE_ALGORITHM; Why don't we preserve the use of CERT_STATUS_INVALID for broken and CERT_STATUS_WEAK_SIGNATURE_ALGORITHM for weak (but not broken) algorithms, and just move MD2 to the broken category and add MD5 to the weak category?
http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate.cc#ne... net/base/x509_certificate.cc:607: verify_result->has_md5) { On 2011/10/24 18:22:31, Chris P. wrote: > > NOTE that we MUST NOT ban the 4 known Verisign MD2-signed root certs. (I don't > know if this code applies to roots, or just end entities and intermediaries?) The signatures in the self-signed certificates of root CAs used as trust anchors are not important. rsleevi: please make sure verify_result->has_md[2,4,5] do not include the root CA certificates. We should document their meanings in net/base/cert_verify_result.h. Thanks!
wtc: In discussing with Chris, I want to make sure we're on the same page: MD4 ---- EE Certs, Intermediates, Roots Today: Banned with CERT_STATUS_INVALID Tomorrow/with this CL: CERT_STATUS_[BROKEN_ALGORITHM?] MD2: ---- EE: Today: Interstitial, CERT_STATUS_WEAK_ALGORITHM Tomorrow: Error, CERT_STATUS_BROKEN_ALGORITHM Intermediates: Today: Interstitial, CERT_STATUS_WEAK_ALGORITHM Tomorrow: Error, CERT_STATUS_BROKEN_ALGORITHM Roots: Today: Interstitial, CERT_STATUS_WEAK_ALGORITHM Tomorrow: Excluding the 3/4 Verisign roots (which at least NSS still recognizes - not sure of OS X/Win recognize them or if they're using the cross-certified intermediates to chain to the SHA1 roots), CERT_STATUS_BROKEN_ALGORITHM For the few Verisign roots... whitelist (no interstitial?) MD5 ---- EE Today: No error Tomorrow: Interstitial, CERT_STATUS_WEAK_ALGORITHM Intermediate: Today: No error Tomorrow: Interstitial, CERT_STATUS_WEAK_ALGORITHM Root: Today: No error Tomorrow: No error Is this correct for everyone? http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate.cc#ne... net/base/x509_certificate.cc:607: verify_result->has_md5) { On 2011/10/24 22:41:14, wtc wrote: > > On 2011/10/24 18:22:31, Chris P. wrote: > > > > NOTE that we MUST NOT ban the 4 known Verisign MD2-signed root certs. (I don't > > know if this code applies to roots, or just end entities and intermediaries?) > > The signatures in the self-signed certificates of root CAs > used as trust anchors are not important. > > rsleevi: please make sure verify_result->has_md[2,4,5] > do not include the root CA certificates. We should document > their meanings in net/base/cert_verify_result.h. Thanks! The logic currently includes roots (both has_mdX and has_mdX_ca have made no remark towards roots]. I will adjust that accordingly. http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate_win.cc File net/base/x509_certificate_win.cc (left): http://codereview.chromium.org/8374020/diff/1/net/base/x509_certificate_win.c... net/base/x509_certificate_win.cc:808: verify_result->cert_status |= CERT_STATUS_WEAK_SIGNATURE_ALGORITHM; On 2011/10/24 22:36:42, wtc wrote: > > Why don't we preserve the use of CERT_STATUS_INVALID for > broken and CERT_STATUS_WEAK_SIGNATURE_ALGORITHM for > weak (but not broken) algorithms, and just move MD2 to > the broken category and add MD5 to the weak category? How about a new error code? Is there any measurable cost of using one? This goes back to the more/better diagnostics side - if/when people encounter this message, or the interstitial, it seems useful to know why. Especially if/when the MD5 kill-bit is turned on.
On Mon, Oct 24, 2011 at 7:16 PM, <rsleevi@chromium.org> wrote: > wtc: In discussing with Chris, I want to make sure we're on the same page: I don't believe that the algorithm of the self-signature on a root matters at all. Thus I don't think this logic should apply to roots. Cheers AGL
> I don't believe that the algorithm of the self-signature on a root > matters at all. Thus I don't think this logic should apply to roots. For system roots, I agree. For locally-installed roots, it seems better safe than sorry to pre-emptively define away silly behavior.
On 2011/10/24 23:22:56, Chris Palmer wrote: > > For locally-installed roots, it seems better safe than sorry to > pre-emptively define away silly behavior. A root (or rather, trust anchor) can even be specified as a bare public key. It doesn't need to come in form of a self-signed cert. This is why the signature in a self-signed root cert doesn't really matter.
On 2011/10/24 23:22:56, Chris Palmer wrote: > > I don't believe that the algorithm of the self-signature on a root > > matters at all. Thus I don't think this logic should apply to roots. > > For system roots, I agree. > > For locally-installed roots, it seems better safe than sorry to > pre-emptively define away silly behavior. agl: Sounds good, but here's a new variation that I'm curious the behaviour on, and was discussing with Chris. If a server supplies an incomplete chain, or a chain cannot be located to a trusted root, but md[2/4/5] is present, what is the expected behaviour? Should the user be interstitialed for the "Unknown Root" (which I interpret as the more serious error here), but not for the md[2,4,5]? If the md[2,4,5] would be an error (rather than an interstitial), should that error still be shown (preventing the user from continuing), or should they be shown the "Unknown Root" interstitial, and allowed to procede? This may only be relevant for MD5 - I'm not aware of many/any MD2/MD4 intermediates still floating around. I'm just wanting to understand the relative priority of the errors. My own inclination is: 1) If the server /supplied/ an mdX certificate, and mdX is an error, then show them the error 2) If the client /located/ an mdX certificate (AIA, system store, cert cache, w/e), and mdX is an error, but did not locate a root, show them the untrusted root interstitial. 3) If the certificate chain was chained to a root, and anything but the root had mdX, treat it however mdX is treated (error, interstitial)
On 2011/10/24 23:16:32, Ryan Sleevi wrote: > wtc: In discussing with Chris, I want to make sure we're on the same page: > > MD4 > ---- > EE Certs, Intermediates, Roots > Today: Banned with CERT_STATUS_INVALID > Tomorrow/with this CL: CERT_STATUS_[BROKEN_ALGORITHM?] We should continue to use CERT_STATUS_INVALID for broken signature algorithms. It is not necessary to add a new cert status flag and error code for broken signature algorithms. CERT_STATUS_WEAK_ALGORITHM should continue to be treated as an overridable certificate error. Self-signed root certs should be excluded from the signature algorithm checks.
Thanks for the feedback all. Now that all the platform-specific changes have landed, as well as the unittests, I think this is good for a second round. Signatures on trusted roots are ignored (covered in the previous unittests that were added). MD2 is demoted from WEAK -> INVALID (non-overridable), MD5 is demoted from OK -> WEAK (interstitialed)
just one question from me.. http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.c... net/base/x509_certificate.cc:602: rv = MapCertStatusToNetError(verify_result->cert_status); I just noticed all three of these MapCertStatusToNetError may overwrite a more serious error in |rv| with a less critical one. I can't see a pretty way to factor it out, but possibly we want to guard them: if (rv == OK) rv = MapCertStatusToNetError(verify_result->cert_status); (internally MapCertStatusToNetError attempts to report the most serious error in rv, we can do that in the general case here as rv may already contain a platform specific error of unknown severity)
http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.c... net/base/x509_certificate.cc:602: rv = MapCertStatusToNetError(verify_result->cert_status); As I understand it, only CERT_STATUS_WEAK_SIGNATURE_ALGORITHM is potentially less severe than what might already be set. CERT_STATUS_INVALID and CERT_STATUS_AUTHORITY_INVALID are already fully fatal, right?
http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.c... net/base/x509_certificate.cc:602: rv = MapCertStatusToNetError(verify_result->cert_status); On 2011/11/03 17:47:04, Chris P. wrote: > As I understand it, only CERT_STATUS_WEAK_SIGNATURE_ALGORITHM is potentially > less severe than what might already be set. CERT_STATUS_INVALID and > CERT_STATUS_AUTHORITY_INVALID are already fully fatal, right? The case I was thinking of was VerifyInternal may return something super-duper-severe, but then any of there overwrite it here. In practice though I agree this would only be a risk for the non-fatal WEAK_SIGNATURE_ALGORITHM case .
http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/12003/net/base/x509_certificate.c... net/base/x509_certificate.cc:602: rv = MapCertStatusToNetError(verify_result->cert_status); On 2011/11/03 20:01:27, joth wrote: > On 2011/11/03 17:47:04, Chris P. wrote: > > As I understand it, only CERT_STATUS_WEAK_SIGNATURE_ALGORITHM is potentially > > less severe than what might already be set. CERT_STATUS_INVALID and > > CERT_STATUS_AUTHORITY_INVALID are already fully fatal, right? > > The case I was thinking of was VerifyInternal may return something > super-duper-severe, but then any of there overwrite it here. > In practice though I agree this would only be a risk for the non-fatal > WEAK_SIGNATURE_ALGORITHM case . Good catch. You're absolutely correct that this could potentially mask errors (primarily, library errors, from looking at the implementations). I've updated it to reflect your suggestion - to only replace |rv| when the existing rv == OK, at least for the MD5 case. This does mean that there is the potential for system library errors to be replaced with a more generic error (ERR_CERT_INVALID) when using MD2/MD4 . These will still result in non-user-overridable errors though. I'm not thrilled with this, but I'm less thrilled about the idea of pushing the 'severity' of errors (user-overridable vs fatal) further into net/ from content/ && chrome/.
LGTM (but IANAO)
Patch Set 4 LGTM. http://codereview.chromium.org/8374020/diff/14002/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/14002/net/base/x509_certificate.c... net/base/x509_certificate.cc:604: // with a benign, user-overridable error. This is a subtle problem. Perhaps the test should be if (rv == OK || IsCertificateError(rv)) ? http://codereview.chromium.org/8374020/diff/14002/net/base/x509_certificate_u... File net/base/x509_certificate_unittest.cc (right): http://codereview.chromium.org/8374020/diff/14002/net/base/x509_certificate_u... net/base/x509_certificate_unittest.cc:1563: (verify_result.cert_status & CERT_STATUS_INVALID)); The parentheses are not necessary here and on line 1571 below. http://codereview.chromium.org/8374020/diff/14002/net/base/x509_certificate_u... net/base/x509_certificate_unittest.cc:1575: // be rejected. Nit: "but be rejected" does not apply to the last case on line 1582.
In light of Palmer's < 1023 check, I'm wondering whether or not incomplete chains should have these rules applied to them at all. Does it matter if an incomplete/self-signed chain has an MD[2,4,5] certificate in it? After all, if the identity isn't known/trustworthy, and the user has to make a leap of faith, why should the signature algorithm matter? However, if the goal is to better educate users overall, and to get more sysadmins to recognize the risks in general of using weak algs, this is probably fine. http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.c... net/base/x509_certificate.cc:615: if (rv == OK || (IsCertificateError(rv) && has_cert_status_error)) I believe the following check should be a sufficient guard against any extra overwrites, but there still remains the possibility of a more informative error being masked. Using simply IsCertificateError(rv) as the check can miss situations in _win and _mac where the library calls fail, but are mapped to certificate errors. Normally fatal, if just IsCE() was used, these would be made into warnings. Using simply IsCertStatusError() equally has problems, in that there are times when a system API call may fail, and the error code is not set to a certificate error (eg: ERR_FAILED). ->cert_status may only have minor errors, but we want to treat the error as fatal. Using both should hopefully be sufficient. If/as we add more checks, and the possibility of more warnings, then this may need to be revisited.
wtc: Would you mind double checking the explanation of Patchset 8 and making sure there isn't something obvious I've missed? I've also held off on landing this as the discussion (last week) on other CLs observed was that there would be no new Dev between now and M17, so there wasn't a chance for changes to go live. While I would like to think that this should "just work" and not cause any issues, the real world of SSL is ugly, messy, and sometimes just downright idiotic, so I didn't want to push this change without having a chance to bake a little. However, if the feeling of the security-team/Googlers is that this would be advantageous for M17 (as I see several other security pushes, most notably download protection), then let me know (or just tick the CQ box), and we can land prior to the M17 branch.
On Tue, Nov 29, 2011 at 10:27 PM, <rsleevi@chromium.org> wrote: > wtc: Would you mind double checking the explanation of Patchset 8 and making > However, if the feeling of the security-team/Googlers is that this would be > advantageous for M17 (as I see several other security pushes, most notably > download protection), then let me know (or just tick the CQ box), and we can > land prior to the M17 branch. My (weak) preference would be to have only one of "blocking RSA < 1023" and this in a single release. However, I don't see that we have the code to block small RSA keys in the tree yet. Cheers AGL
On Wed, Nov 30, 2011 at 7:16 AM, Adam Langley <agl@chromium.org> wrote: > My (weak) preference would be to have only one of "blocking RSA < > 1023" and this in a single release. However, I don't see that we have > the code to block small RSA keys in the tree yet. I share this preference. Unfortunately, I can't commit to getting the RSA < 1023 patch in by 6 Dec, because I'm sheriff this week. I'm currently hung on up generating really solid unit tests for that check, and I don't want to half-ass testing. Therefore, let's just go ahead and say that RSA < 1023 will go in 18, and this change can go in 17.
On 2011/11/30 03:27:30, Ryan Sleevi wrote: > wtc: Would you mind double checking the explanation of Patchset 8 and making > sure there isn't something obvious I've missed? Sorry about the delay. I will check the diffs between Patch Sets 4 and 8 tomorrow (Friday).
Patch Set 8 LGTM. http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.c... net/base/x509_certificate.cc:608: bool has_cert_status_error = Nit: has_cert_status_error => cert_status_has_error ? http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.c... net/base/x509_certificate.cc:613: // possibility of replacing a more fatal error (such as an OS/library Nit: remove "the possibility of". http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.c... net/base/x509_certificate.cc:615: if (rv == OK || (IsCertificateError(rv) && has_cert_status_error)) I'm still not convinced that we should check has_cert_status_error here. On 2011/11/20 00:17:00, Ryan Sleevi wrote: > > Using simply IsCertificateError(rv) as the check can miss situations in _win and > _mac where the library calls fail, but are mapped to certificate errors. > Normally fatal, if just IsCE() was used, these would be made into warnings. Can you give a concrete example? I think this should not happen. If |rv| is a certificate error, it should be the most serious error in verify_result->cert_status. If this property is not maintained, it is a bug. http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate_u... File net/base/x509_certificate_unittest.cc (right): http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate_u... net/base/x509_certificate_unittest.cc:1590: // variations are fatal. The second sentence is hard to understand. One possible interpretation is as follows: If a root cert is present, then check that the chain was rejected if any weak algorithms are present. The error code is dependent on the algorithm, although all variations are fatal. This is only checked when a root cert is present, as the error reported for incomplete chains with weak algorithms varies between implementations. Another possible interpretation is as follows: If a root cert is present, then check that the chain was rejected if any weak algorithms are present. This is only checked when a root cert is present, as the error reported for incomplete chains with weak algorithms varies between implementations and depends on the algorithm, although all variations are fatal.
http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.c... net/base/x509_certificate.cc:615: if (rv == OK || (IsCertificateError(rv) && has_cert_status_error)) On 2011/12/02 23:04:59, wtc wrote: > > I'm still not convinced that we should check > has_cert_status_error here. > > On 2011/11/20 00:17:00, Ryan Sleevi wrote: > > > > Using simply IsCertificateError(rv) as the check can miss situations in _win > and > > _mac where the library calls fail, but are mapped to certificate errors. > > Normally fatal, if just IsCE() was used, these would be made into warnings. > > Can you give a concrete example? I think this should > not happen. If |rv| is a certificate error, it should > be the most serious error in verify_result->cert_status. > If this property is not maintained, it is a bug. Then it's a bug - MapSecurityError() can return a certificate error without updating CertStatus - these specifically were the two lines that concerned me. http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/base/x509_certifi... http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/base/x509_certifi... This is also potentially dangerous if MapSecurityError and MapCertErrrorToCertStatus get out of sync (but not presently a bug) http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/base/x509_certifi... OS X is fine because NetErrorFromOSStatus will never return a certificate error, and OpenSSL is fine because it only sets CertStatus and then returns the error mapped from CertStatus. If this is unexpected (and it sounds like it is), then I can just update those three call sites to ensure at least CERT_STATUS_INVALID is set on the cert. The potential problem with this is that it could mask a more meaningful error, but that sounds acceptable. http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate_u... File net/base/x509_certificate_unittest.cc (right): http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate_u... net/base/x509_certificate_unittest.cc:1590: // variations are fatal. On 2011/12/02 23:04:59, wtc wrote: > > The second sentence is hard to understand. > > One possible interpretation is as follows: > If a root cert is present, then check that the chain was > rejected if any weak algorithms are present. The error > code is dependent on the algorithm, although all > variations are fatal. This is only checked when a root > cert is present, as the error reported for incomplete > chains with weak algorithms varies between implementations. > > Another possible interpretation is as follows: > If a root cert is present, then check that the chain was rejected if any > weak algorithms are present. This is only checked when a root cert is > present, as the error reported for incomplete chains with weak algorithms > varies between implementations and depends on the algorithm, although all > variations are fatal. > The latter. I blame serial commas - http://en.wikipedia.org/wiki/Serial_comma#Creating_ambiguity - and will update accordingly.
http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.cc File net/base/x509_certificate.cc (right): http://codereview.chromium.org/8374020/diff/24005/net/base/x509_certificate.c... net/base/x509_certificate.cc:615: if (rv == OK || (IsCertificateError(rv) && has_cert_status_error)) On 2011/12/02 23:54:28, Ryan Sleevi wrote: > > Then it's a bug - MapSecurityError() can return a certificate error without > updating CertStatus - these specifically were the two lines that concerned me. > http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/base/x509_certifi... > http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/base/x509_certifi... It is true that MapSecurityError in x509_certificate_win.cc may return a certificate error, but that is because MapSecurityError has some old code. I don't think CertGetCertificateChain will fail with a certificate error, because it has a much better way to report certificate errors. In any case, you can add code to update verify_result->cert_status if MapSecurityError returns a certificate error.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/rsleevi@chromium.org/8374020/40001
Try job failure for 8374020-40001 (retry) on linux_rel for step "ui_tests". It's a second try, previously, steps "browser_tests, ui_tests" failed. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/rsleevi@chromium.org/8374020/40001
The commit queue went berserk retrying too often for a seemingly flaky test. Builder is win_rel, revision is 114351, job name was 8374020-40001 (retry) (previous was lost) (previous was lost) (previous was lost).
No LGTM from valid reviewers yet.
No LGTM from valid reviewers yet.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/rsleevi@chromium.org/8374020/40001
Change committed as 114432 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
