Revert of Implement authenticator based on SPAKE2 implementation in boringssl.

Revert of Implement authenticator based on SPAKE2 implementation in boringssl. (patchset #5 id:140001 of https://codereview.chromium.org/1759313002/ )

Reason for revert:
This patch added 2 more tests which are now failing on Linux MSan Tests as of build #14316

https://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Tests/builds/14316

Spake2AuthenticatorTest.InvalidSecret (run #1):
[ RUN      ] Spake2AuthenticatorTest.InvalidSecret
==10538==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml remoting/protocol/spake2_authenticator.cc:47:3

and

Spake2AuthenticatorTest.SuccessfulAuth (run #1):
[ RUN      ] Spake2AuthenticatorTest.SuccessfulAuth
==10537==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml remoting/protocol/spake2_authenticator.cc:47:3

Original issue's description:
> Implement authenticator based on SPAKE2 implementation in boringssl.
>
> The new authenticator uses SPAKE2 over Curve25519. It will
> be enabled in host and client in a separate CL.
>
> BUG=589698
>
> Committed: https://crrev.com/bf336334ba59ae7cd150e9cb36a9b248d174a4eb
> Cr-Commit-Position: refs/heads/master@{#379972}

TBR=kelvinp@chromium.org,davidben@chromium.org,arnarb@chromium.org,sergeyu@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=589698
Committed: https://crrev.com/f1dcaac3801ed8d0a8abe62f1496e61fbaf639a7
Cr-Commit-Position: refs/heads/master@{#380365}

[chrishall, 2016-03-10 05:05:15]

Created Revert of Implement authenticator based on SPAKE2 implementation in
boringssl.

[commit-bot: I haz the power, 2016-03-10 05:05:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1778223003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1778223003/1

[commit-bot: I haz the power, 2016-03-10 05:05:43]

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

[commit-bot: I haz the power, 2016-03-10 05:05:44]

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[benwells, 2016-03-10 05:07:02]

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

[benwells, 2016-03-10 05:07:03]

lgtm

[chrishall, 2016-03-10 05:07:21]

The CQ bit was checked by chrishall@chromium.org

[commit-bot: I haz the power, 2016-03-10 05:07:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1778223003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1778223003/1

[Sergey Ulanov, 2016-03-10 05:52:13]

The CQ bit was unchecked by sergeyu@chromium.org

[Sergey Ulanov, 2016-03-10 05:54:45]

I unchecked the commit bit. I believe the crash is a false positive and the test
should be disabled under MSan.
Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
output, but MSan doesn't see that.

[Sergey Ulanov, 2016-03-10 05:55:46]

On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> I unchecked the commit bit. I believe the crash is a false positive and the
test
> should be disabled under MSan.
> Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
> output, but MSan doesn't see that.

fe_cmov() is here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boring...

[chrishall, 2016-03-10 06:06:38]

On 2016/03/10 05:55:46, Sergey Ulanov wrote:
> On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > I unchecked the commit bit. I believe the crash is a false positive and the
> test
> > should be disabled under MSan.
> > Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
> > output, but MSan doesn't see that.
> 
> fe_cmov() is here:
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boring...

the comment for fe_cmov agrees with what you are saying,
when b==0 the state of f isn't relevant, can we not just modify the code to make
sure we initialise f in all states? (since this wouldn't affect output but would
keep MSan happy).

[chrishall, 2016-03-10 06:11:38]

On 2016/03/10 06:06:38, chrishall wrote:
> On 2016/03/10 05:55:46, Sergey Ulanov wrote:
> > On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > fe_cmov() is here:
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boring...
> 
> the comment for fe_cmov agrees with what you are saying,
> when b==0 the state of f isn't relevant, can we not just modify the code to
make
> sure we initialise f in all states? (since this wouldn't affect output but
would
> keep MSan happy).

so fwiw I agree, the code will cancel out any state from f when b is 0

    int32_t x = f[i] ^ g[i];
    x &= b;
    f[i] ^= x;

the `x &= b` will remove any state from f when b is `0`, that is potentially
quite hard for a static checker to catch.

I would much prefer we make sure that in both branches (b==0 and b==1) we make
sure that f is in a known initialised state by updating the caller

Is this too difficult?

[Lei Zhang, 2016-03-10 06:20:26]

On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> I unchecked the commit bit. I believe the crash is a false positive and the
test
> should be disabled under MSan.
> Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
> output, but MSan doesn't see that.

a) Are you sure this is just MSAN being silly and not a real uninit condition?
Valgrind is complaining too.
b) To be pedantic, it's not a crash.

[benwells, 2016-03-10 06:27:03]

On 2016/03/10 06:20:26, Lei Zhang (OOO) wrote:
> On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > I unchecked the commit bit. I believe the crash is a false positive and the
> test
> > should be disabled under MSan.
> > Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
> > output, but MSan doesn't see that.
> 
> a) Are you sure this is just MSAN being silly and not a real uninit condition?
> Valgrind is complaining too.
> b) To be pedantic, it's not a crash.

From a fairly quick look at the code:

The code in question (i.e. the code that calls fe_cmov) is in Base64Encode.
Either what serveyu says is correct, or Base64Encode is being called with
uninitialized data.

I'm confused. If this is indeed a thing that has existed in Base64Encode all
along and MSAN / valgrind didn't deal with it, you'd think we'd have seen this
many times already.

But the new code doesn't seem to be calling Base64Encode with any uninitialized
parameters. So, weird.

[benwells, 2016-03-10 06:27:07]

On 2016/03/10 06:20:26, Lei Zhang (OOO) wrote:
> On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > I unchecked the commit bit. I believe the crash is a false positive and the
> test
> > should be disabled under MSan.
> > Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
> > output, but MSan doesn't see that.
> 
> a) Are you sure this is just MSAN being silly and not a real uninit condition?
> Valgrind is complaining too.
> b) To be pedantic, it's not a crash.

From a fairly quick look at the code:

The code in question (i.e. the code that calls fe_cmov) is in Base64Encode.
Either what serveyu says is correct, or Base64Encode is being called with
uninitialized data.

I'm confused. If this is indeed a thing that has existed in Base64Encode all
along and MSAN / valgrind didn't deal with it, you'd think we'd have seen this
many times already.

But the new code doesn't seem to be calling Base64Encode with any uninitialized
parameters. So, weird.

[chrishall, 2016-03-10 06:41:34]

So looking into this code some more I think that my default position is to
continue on with this revert

I do agree that fe_cmov is technically safe with b==0 and f is unitialised, but
it still does a read from unitialised (which it later cancels out) so I can
understand why an analyser would be confused.

I would much prefer we fix our code, rather than disable this test.



There is a lot of red in memory.fyi right now so:

I think we should go ahead with this revert
we can later discuss how we can re-land this patch

[chrishall, 2016-03-10 06:41:43]

The CQ bit was checked by chrishall@chromium.org

[commit-bot: I haz the power, 2016-03-10 06:42:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1778223003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1778223003/1

[commit-bot: I haz the power, 2016-03-10 06:47:27]

Description was changed from

==========
Revert of Implement authenticator based on SPAKE2 implementation in boringssl.
(patchset #5 id:140001 of https://codereview.chromium.org/1759313002/ )

Reason for revert:
This patch added 2 more tests which are now failing on Linux MSan Tests as of
build #14316 

https://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Test...


Spake2AuthenticatorTest.InvalidSecret (run #1):
[ RUN      ] Spake2AuthenticatorTest.InvalidSecret
==10538==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3


and


Spake2AuthenticatorTest.SuccessfulAuth (run #1):
[ RUN      ] Spake2AuthenticatorTest.SuccessfulAuth
==10537==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3





Original issue's description:
> Implement authenticator based on SPAKE2 implementation in boringssl.
> 
> The new authenticator uses SPAKE2 over Curve25519. It will
> be enabled in host and client in a separate CL.
> 
> BUG=589698
> 
> Committed: https://crrev.com/bf336334ba59ae7cd150e9cb36a9b248d174a4eb
> Cr-Commit-Position: refs/heads/master@{#379972}

TBR=kelvinp@chromium.org,davidben@chromium.org,arnarb@chromium.org,sergeyu@ch...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=589698
==========

to

==========
Revert of Implement authenticator based on SPAKE2 implementation in boringssl.
(patchset #5 id:140001 of https://codereview.chromium.org/1759313002/ )

Reason for revert:
This patch added 2 more tests which are now failing on Linux MSan Tests as of
build #14316 

https://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Test...


Spake2AuthenticatorTest.InvalidSecret (run #1):
[ RUN      ] Spake2AuthenticatorTest.InvalidSecret
==10538==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3


and


Spake2AuthenticatorTest.SuccessfulAuth (run #1):
[ RUN      ] Spake2AuthenticatorTest.SuccessfulAuth
==10537==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3





Original issue's description:
> Implement authenticator based on SPAKE2 implementation in boringssl.
> 
> The new authenticator uses SPAKE2 over Curve25519. It will
> be enabled in host and client in a separate CL.
> 
> BUG=589698
> 
> Committed: https://crrev.com/bf336334ba59ae7cd150e9cb36a9b248d174a4eb
> Cr-Commit-Position: refs/heads/master@{#379972}

TBR=kelvinp@chromium.org,davidben@chromium.org,arnarb@chromium.org,sergeyu@ch...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=589698
==========

[commit-bot: I haz the power, 2016-03-10 06:47:28]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-10 06:49:47]

Description was changed from

==========
Revert of Implement authenticator based on SPAKE2 implementation in boringssl.
(patchset #5 id:140001 of https://codereview.chromium.org/1759313002/ )

Reason for revert:
This patch added 2 more tests which are now failing on Linux MSan Tests as of
build #14316 

https://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Test...


Spake2AuthenticatorTest.InvalidSecret (run #1):
[ RUN      ] Spake2AuthenticatorTest.InvalidSecret
==10538==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3


and


Spake2AuthenticatorTest.SuccessfulAuth (run #1):
[ RUN      ] Spake2AuthenticatorTest.SuccessfulAuth
==10537==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3





Original issue's description:
> Implement authenticator based on SPAKE2 implementation in boringssl.
> 
> The new authenticator uses SPAKE2 over Curve25519. It will
> be enabled in host and client in a separate CL.
> 
> BUG=589698
> 
> Committed: https://crrev.com/bf336334ba59ae7cd150e9cb36a9b248d174a4eb
> Cr-Commit-Position: refs/heads/master@{#379972}

TBR=kelvinp@chromium.org,davidben@chromium.org,arnarb@chromium.org,sergeyu@ch...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=589698
==========

to

==========
Revert of Implement authenticator based on SPAKE2 implementation in boringssl.
(patchset #5 id:140001 of https://codereview.chromium.org/1759313002/ )

Reason for revert:
This patch added 2 more tests which are now failing on Linux MSan Tests as of
build #14316

https://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Test...

Spake2AuthenticatorTest.InvalidSecret (run #1):
[ RUN      ] Spake2AuthenticatorTest.InvalidSecret
==10538==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3

and

Spake2AuthenticatorTest.SuccessfulAuth (run #1):
[ RUN      ] Spake2AuthenticatorTest.SuccessfulAuth
==10537==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14bb0fd in ?? third_party/modp_b64/modp_b64.cc:91:20
    #1 0xdcf2f6 in Base64Encode base/base64.cc:18:24
    #2 0x12d6e6c in EncodeBinaryValueToXml
remoting/protocol/spake2_authenticator.cc:47:3

Original issue's description:
> Implement authenticator based on SPAKE2 implementation in boringssl.
>
> The new authenticator uses SPAKE2 over Curve25519. It will
> be enabled in host and client in a separate CL.
>
> BUG=589698
>
> Committed: https://crrev.com/bf336334ba59ae7cd150e9cb36a9b248d174a4eb
> Cr-Commit-Position: refs/heads/master@{#379972}

TBR=kelvinp@chromium.org,davidben@chromium.org,arnarb@chromium.org,sergeyu@ch...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=589698

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

[commit-bot: I haz the power, 2016-03-10 06:49:48]

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

[Lei Zhang, 2016-03-10 06:52:28]

On 2016/03/10 06:20:26, Lei Zhang (OOO) wrote:
> On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > I unchecked the commit bit. I believe the crash is a false positive and the
> test
> > should be disabled under MSan.
> > Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect the
> > output, but MSan doesn't see that.
> 
> a) Are you sure this is just MSAN being silly and not a real uninit condition?
> Valgrind is complaining too.
> b) To be pedantic, it's not a crash.

If you run the tests, you'll see b != 0 in most calls to x25519_ge_scalarmult(),
so MSAN is correctly looking at the memory access AFAICT.

[benwells, 2016-03-10 07:03:54]

On 2016/03/10 06:52:28, Lei Zhang (OOO) wrote:
> On 2016/03/10 06:20:26, Lei Zhang (OOO) wrote:
> > On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > > I unchecked the commit bit. I believe the crash is a false positive and
the
> > test
> > > should be disabled under MSan.
> > > Take a look at fe_cmov(). If b=0 and f is initialized it doesn't affect
the
> > > output, but MSan doesn't see that.
> > 
> > a) Are you sure this is just MSAN being silly and not a real uninit
condition?
> > Valgrind is complaining too.
> > b) To be pedantic, it's not a crash.
> 
> If you run the tests, you'll see b != 0 in most calls to
x25519_ge_scalarmult(),
> so MSAN is correctly looking at the memory access AFAICT.

The full report for one of the tests is here:
https://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Test...

There are some interesting clues to track down in the sections detailing where
the uninitialized memory was stored.

[Sergey Ulanov, 2016-03-10 07:24:04]

Base64Encode() is called with data that's being generated by Curve25519
implementation in boringssl, which uses fe_cmov() internally. I.e. this
warning is not related to Base64Encode() per-se. fe_cmov() is in the bottom
of the origin trace provided by MSan, which is why I think MSan is confused
about it. Spake2AuthenticatorTest.SuccessfulAuth test would fail if any
data passed to Base64Encode() was actually uninitialized.

On Wed, Mar 9, 2016 at 10:27 PM, <benwells@chromium.org> wrote:

> On 2016/03/10 06:20:26, Lei Zhang (OOO) wrote:
> > On 2016/03/10 05:54:45, Sergey Ulanov wrote:
> > > I unchecked the commit bit. I believe the crash is a false positive
> and the
> > test
> > > should be disabled under MSan.
> > > Take a look at fe_cmov(). If b=0 and f is initialized it doesn't
> affect the
> > > output, but MSan doesn't see that.
> >
> > a) Are you sure this is just MSAN being silly and not a real uninit
> condition?
> > Valgrind is complaining too.
> > b) To be pedantic, it's not a crash.
>
> From a fairly quick look at the code:
>
> The code in question (i.e. the code that calls fe_cmov) is in Base64Encode.
> Either what serveyu says is correct, or Base64Encode is being called with
> uninitialized data.
>
> I'm confused. If this is indeed a thing that has existed in Base64Encode
> all
> along and MSAN / valgrind didn't deal with it, you'd think we'd have seen
> this
> many times already.
>
> But the new code doesn't seem to be calling Base64Encode with any
> uninitialized
> parameters. So, weird.
>
> https://codereview.chromium.org/1778223003/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Sergey Ulanov, 2016-03-10 21:55:14]

Looking at the code again the problem comes from this piece of code:
    unsigned j;
    ge_cached selected;
    for (j = 0; j < 16; j++) {
      cmov_cached(&selected, &Ai[j], equal(j, index));
    }

See
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boring...
Here index is guaranteed to be in range [0,15] and cmov_cached() moves Ai[j] to
selected when j==index, i.e. selected always guaranteed to be initialized and
the code is correct. I'm going to reland my change with the test disabled in
MSan and will file a bug to get boringssl fixed to add explicit initialization
of |selected| if possible.

[davidben, 2016-03-10 21:57:57]

On 2016/03/10 21:55:14, Sergey Ulanov wrote:
> Looking at the code again the problem comes from this piece of code:
>     unsigned j;
>     ge_cached selected;
>     for (j = 0; j < 16; j++) {
>       cmov_cached(&selected, &Ai[j], equal(j, index));
>     }
> 
> See
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boring...
> Here index is guaranteed to be in range [0,15] and cmov_cached() moves Ai[j]
to
> selected when j==index, i.e. selected always guaranteed to be initialized and
> the code is correct. I'm going to reland my change with the test disabled in
> MSan and will file a bug to get boringssl fixed to add explicit initialization
> of |selected| if possible.

See https://crbug.com/593540. The fix is already in and the DEPS roll is in the
CQ.

[Sergey Ulanov, 2016-03-10 22:26:59]

On Thu, Mar 10, 2016 at 1:57 PM, <davidben@chromium.org> wrote:
>
> See https://crbug.com/593540. The fix is already in and the DEPS roll is
> in the
> CQ.
>

awesome, thanks!

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[davidben, 2016-03-10 22:44:56]

On 2016/03/10 22:26:59, Sergey Ulanov wrote:
> On Thu, Mar 10, 2016 at 1:57 PM, <mailto:davidben@chromium.org> wrote:
> >
> > See https://crbug.com/593540. The fix is already in and the DEPS roll is
> > in the
> > CQ.
> >
> 
> awesome, thanks!
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

Unfortunately, the CQ is completely non-functional right now and it's late over
in CAM. :-(

If this Nth attempt fails and you're still in the office, feel free to re-check
the CQ box until it finally gets in.
https://codereview.chromium.org/1786463002/

[chromium-reviews, 2016-03-10 23:18:34]

I'll watch it and set the CQ bit!
On Thu, Mar 10, 2016 at 14:44 <davidben@chromium.org> wrote:

> On 2016/03/10 22:26:59, Sergey Ulanov wrote:
>
> > On Thu, Mar 10, 2016 at 1:57 PM, <mailto:davidben@chromium.org> wrote:
> > >
> > > See https://crbug.com/593540. The fix is already in and the DEPS roll
> is
> > > in the
> > > CQ.
> > >
> >
> > awesome, thanks!
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Chromium-reviews" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>
> Unfortunately, the CQ is completely non-functional right now and it's late
> over
> in CAM. :-(
>
> If this Nth attempt fails and you're still in the office, feel free to
> re-check
> the CQ box until it finally gets in.
> https://codereview.chromium.org/1786463002/
>
> https://codereview.chromium.org/1778223003/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.