crypto: re-add crypto.timingSafeEqual #8304

Closed
wants to merge 16 commits into
from

Conversation

Projects
None yet
7 participants
@not-an-aardvark
Member

not-an-aardvark commented Aug 27, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

crypto test

Description of change

Refs: #8040, #8203, #8225

This re-adds crypto.timingSafeEqual, which was previously reverted due to test failures and concerns that the implementation might not be timing-safe.

Some investigation is still needed to determine why the tests are failing on ARM systems.

not-an-aardvark added some commits Aug 24, 2016

@Trott

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 27, 2016

Member

Looks like the arm tests are failing like before, but linux is working now.

One of the arm tests had a t-value of -32 (i.e. checking unequal buffers took significantly longer than checking equal buffers). This is the opposite of what was happening on linux, so it seems unlikely to be the same problem.

Member

not-an-aardvark commented Aug 27, 2016

Looks like the arm tests are failing like before, but linux is working now.

One of the arm tests had a t-value of -32 (i.e. checking unequal buffers took significantly longer than checking equal buffers). This is the opposite of what was happening on linux, so it seems unlikely to be the same problem.

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

I added a temporary console.log to output more detailed info if the tests fail.

I don't have access to any ARM hardware, so debugging/reproducing this locally might be tricky. (I suppose I could look into emulating one.)

Member

not-an-aardvark commented Aug 28, 2016

I added a temporary console.log to output more detailed info if the tests fail.

I don't have access to any ARM hardware, so debugging/reproducing this locally might be tricky. (I suppose I could look into emulating one.)

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 28, 2016

Member

Here's a run of the test 100 times on armv7-wheezy. (Hopefully I did it right. It's building right now...) https://ci.nodejs.org/job/node-stress-single-test/871/nodes=armv7-wheezy/console

Member

Trott commented Aug 28, 2016

Here's a run of the test 100 times on armv7-wheezy. (Hopefully I did it right. It's building right now...) https://ci.nodejs.org/job/node-stress-single-test/871/nodes=armv7-wheezy/console

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

Wow, that's a lot of numbers. Output for posterity

Member

not-an-aardvark commented Aug 28, 2016

Wow, that's a lot of numbers. Output for posterity

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

So I'm not sure whether this is related to the test failures, but I noticed that a vast majority of the benchmark times (over 98%) ended with the digit 1. Is this just a known quirk of process.hrtime()?

Member

not-an-aardvark commented Aug 28, 2016

So I'm not sure whether this is related to the test failures, but I noticed that a vast majority of the benchmark times (over 98%) ended with the digit 1. Is this just a known quirk of process.hrtime()?

@Trott

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

Of the 52 times that the previous test failed, all of the t-values were positive numbers between 3 and 7.

I pushed another test commit to flip the order of the benchmarks; could we run another stress-test? If the problem is caused by a security issue with the timingSafeEqual implementation, we would expect the t-values to still be positive numbers after swapping. If the problem is caused by something else (e.g. V8 optimization), the t-values will be negative numbers after swapping.

Member

not-an-aardvark commented Aug 28, 2016

Of the 52 times that the previous test failed, all of the t-values were positive numbers between 3 and 7.

I pushed another test commit to flip the order of the benchmarks; could we run another stress-test? If the problem is caused by a security issue with the timingSafeEqual implementation, we would expect the t-values to still be positive numbers after swapping. If the problem is caused by something else (e.g. V8 optimization), the t-values will be negative numbers after swapping.

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

That time all the t-values were numbers between -3 and -7, i.e. the comparisons between unequal buffers took longer.

Based on that, I'm pretty confident that this is not a security issue; whichever pair of buffers is compared first ends up with longer benchmarks, regardless of the actual contents of the buffers.

Member

not-an-aardvark commented Aug 28, 2016

That time all the t-values were numbers between -3 and -7, i.e. the comparisons between unequal buffers took longer.

Based on that, I'm pretty confident that this is not a security issue; whichever pair of buffers is compared first ends up with longer benchmarks, regardless of the actual contents of the buffers.

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

Pushed another commit to alternate the order of the benchmarks on each iteration.

(This might not actually solve this issue, depending on whether it's only the first benchmark overall that matters, or the first benchmark of each iteration. But it's probably worth trying anyway since it would be nice to have non-flaky tests even if it's not a security problem.)

Member

not-an-aardvark commented Aug 28, 2016

Pushed another commit to alternate the order of the benchmarks on each iteration.

(This might not actually solve this issue, depending on whether it's only the first benchmark overall that matters, or the first benchmark of each iteration. But it's probably worth trying anyway since it would be nice to have non-flaky tests even if it's not a security problem.)

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

Whoa, that didn't help; that time they all failed with positive t-values.

It's interesting that before that change, the test was failing almost exactly half of the time. I'm guessing there's some optimization that was kicking in at a random point, causing the test to fail if it kicked in between invocations, and pass if it kicked in after a pair of invocations is finished.

(I remember we reached something similar to this conclusion last time and tried manually optimizing the function without success.)

Member

not-an-aardvark commented Aug 28, 2016

Whoa, that didn't help; that time they all failed with positive t-values.

It's interesting that before that change, the test was failing almost exactly half of the time. I'm guessing there's some optimization that was kicking in at a random point, causing the test to fail if it kicked in between invocations, and pass if it kicked in after a pair of invocations is finished.

(I remember we reached something similar to this conclusion last time and tried manually optimizing the function without success.)

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

To prevent V8 from optimizing the cases differently, I split the runBenchmark function into runEqualBenchmark and runUnequalBenchmark.

(This was also attempted in #8203 (comment), but it seems like there weren't any timing failures on ARM during that CI run, so it might solve the issue.)

Member

not-an-aardvark commented Aug 28, 2016

To prevent V8 from optimizing the cases differently, I split the runBenchmark function into runEqualBenchmark and runUnequalBenchmark.

(This was also attempted in #8203 (comment), but it seems like there weren't any timing failures on ARM during that CI run, so it might solve the issue.)

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

That version passed 96/100 times. 🎉

I have no idea what happened with the 4 failures though; t-values of 6, -31, -33, and 3.

Member

not-an-aardvark commented Aug 28, 2016

That version passed 96/100 times. 🎉

I have no idea what happened with the 4 failures though; t-values of 6, -31, -33, and 3.

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Aug 28, 2016

Member

I think this is ready for review; the tests are slightly flaky on ARM, but they seem to pass somewhat consistently on other platforms, and we have fairly good reason to believe that the inconsistencies are not a security problem.

(The implementation in this PR is the same as in #8040; only the tests have changed.)

Member

not-an-aardvark commented Aug 28, 2016

I think this is ready for review; the tests are slightly flaky on ARM, but they seem to pass somewhat consistently on other platforms, and we have fairly good reason to believe that the inconsistencies are not a security problem.

(The implementation in this PR is the same as in #8040; only the tests have changed.)

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 30, 2016

Member

I guess let's start with a regular CI run: https://ci.nodejs.org/job/node-test-pull-request/3881/

Member

Trott commented Aug 30, 2016

I guess let's start with a regular CI run: https://ci.nodejs.org/job/node-test-pull-request/3881/

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 30, 2016

Member

Woo! tentative LGTM assuming CI looks green.

Member

jasnell commented Aug 30, 2016

Woo! tentative LGTM assuming CI looks green.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 30, 2016

Member

Woo! tentative LGTM assuming CI looks green.

CI is not green. Still some work to do, but it's a lot closer. I want to buy @not-an-aardvark a pizza or whatever the appropriate expression of gratitude is when someone is doing great work on something but progress is slow because the problem is hard.

Member

Trott commented Aug 30, 2016

Woo! tentative LGTM assuming CI looks green.

CI is not green. Still some work to do, but it's a lot closer. I want to buy @not-an-aardvark a pizza or whatever the appropriate expression of gratitude is when someone is doing great work on something but progress is slow because the problem is hard.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 30, 2016

Member

If you're buying the pizza, I'll buy the accompanying beverage of choice.
This is good work.

On Monday, August 29, 2016, Rich Trott notifications@github.com wrote:

Woo! tentative LGTM assuming CI looks green.

CI is not green. Still some work to do, but it's a lot closer. I want to
buy @not-an-aardvark https://github.com/not-an-aardvark a pizza or
whatever the appropriate expression of gratitude is when someone is doing
great work on something but progress is slow because the problem is hard.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8304 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eSa29Z9km_gu77-Tj7DA2SJUR1QUks5qk6NugaJpZM4JuxC_
.

Member

jasnell commented Aug 30, 2016

If you're buying the pizza, I'll buy the accompanying beverage of choice.
This is good work.

On Monday, August 29, 2016, Rich Trott notifications@github.com wrote:

Woo! tentative LGTM assuming CI looks green.

CI is not green. Still some work to do, but it's a lot closer. I want to
buy @not-an-aardvark https://github.com/not-an-aardvark a pizza or
whatever the appropriate expression of gratitude is when someone is doing
great work on something but progress is slow because the problem is hard.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8304 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eSa29Z9km_gu77-Tj7DA2SJUR1QUks5qk6NugaJpZM4JuxC_
.

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Sep 1, 2016

Member

I added a few eval statements to some of the functions in the test to hopefully prevent V8 from optimizing the time-sensitive parts of the test.

Could we run another ARM stress-test?

Member

not-an-aardvark commented Sep 1, 2016

I added a few eval statements to some of the functions in the test to hopefully prevent V8 from optimizing the time-sensitive parts of the test.

Could we run another ARM stress-test?

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 1, 2016

Member

Regular CI: https://ci.nodejs.org/job/node-test-commit/4868/

Having trouble getting the armv7-wheezy stress test to start. Will ping node-build on IRC. Should be available from https://ci.nodejs.org/job/node-stress-single-test/878/ when it starts working.

Member

Trott commented Sep 1, 2016

Regular CI: https://ci.nodejs.org/job/node-test-commit/4868/

Having trouble getting the armv7-wheezy stress test to start. Will ping node-build on IRC. Should be available from https://ci.nodejs.org/job/node-stress-single-test/878/ when it starts working.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 1, 2016

Member

Actually, I think we just have to be patient for the stress test. It's probably waiting on the regular CI test to finish so it can use that armv7-wheezy host.

Member

Trott commented Sep 1, 2016

Actually, I think we just have to be patient for the stress test. It's probably waiting on the regular CI test to finish so it can use that armv7-wheezy host.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 1, 2016

Member

Assorted failures in Linux too and possibly elsewhere. I'll stop listing them individually here now.

Member

Trott commented Sep 1, 2016

Assorted failures in Linux too and possibly elsewhere. I'll stop listing them individually here now.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 1, 2016

Member

Stress test: https://ci.nodejs.org/job/node-stress-single-test/878/nodes=armv7-wheezy/console

I terminated the CI and stress test as it seems like there are enough failures to determine that eval('') is not the solution, unfortunately.

Member

Trott commented Sep 1, 2016

Stress test: https://ci.nodejs.org/job/node-stress-single-test/878/nodes=armv7-wheezy/console

I terminated the CI and stress test as it seems like there are enough failures to determine that eval('') is not the solution, unfortunately.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 3, 2016

Member

This one is looking really, really good...

Member

Trott commented Sep 3, 2016

This one is looking really, really good...

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Sep 3, 2016

Member

🎉, looks like everything is green except the unrelated Raspberry Pi failures.

Member

not-an-aardvark commented Sep 3, 2016

🎉, looks like everything is green except the unrelated Raspberry Pi failures.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 3, 2016

Member

🎉 Yes! And the stress test has run 1735 times without a failure so far. (Going to let it run the full 9999 runs, though...)

In the meantime, I guess we're at the point where it's:

  • hopefully @nodejs/crypto can review again the implementation and the test
  • do we need to update the documentation to cover any of the stuff that required all this effort to work around in the test? or is it not really related/relevant?

I imagine this is semver-minor so I'll apply that label now...

Member

Trott commented Sep 3, 2016

🎉 Yes! And the stress test has run 1735 times without a failure so far. (Going to let it run the full 9999 runs, though...)

In the meantime, I guess we're at the point where it's:

  • hopefully @nodejs/crypto can review again the implementation and the test
  • do we need to update the documentation to cover any of the stuff that required all this effort to work around in the test? or is it not really related/relevant?

I imagine this is semver-minor so I'll apply that label now...

@Trott Trott added the semver-minor label Sep 3, 2016

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Sep 3, 2016

Member

do we need to update the documentation to cover any of the stuff that required all this effort to work around in the test? or is it not really related/relevant?

I would say there are three different categories of issues that we've faced:

  1. Code was timing-safe, but caused problems for this test due to our benchmarking strategy.
  2. Code was timing-unsafe due to unsafe usage/bug in crypto.timingSafeEqual.
  3. Code was timing-unsafe due to something other than crypto.timingSafeEqual.

If we're going to add info on timing-safe code to the docs, it should be to address issues in category (2) or (3). Documentation for category (2) is very important (e.g. "how to use crypto.timingSafeEqual safely"), and category (3) is useful but not as important/relevant ("how to write timing-safe code in JS").

I don't think we encountered any issues in category (2).

I have a very vague idea of how to prevent issues in category (3) based on what worked in this PR, but I don't think I know enough about these issues to write docs on how to prevent them. I don't want the docs to mislead people into thinking that their code is safe (because they followed instructions in the crypto docs) if it actually isn't.

tl;dr: The documentation can probably be improved, but I don't think it's urgent to do so, and it should probably be done by someone with more knowledge of V8 (presumably in a different PR).

Member

not-an-aardvark commented Sep 3, 2016

do we need to update the documentation to cover any of the stuff that required all this effort to work around in the test? or is it not really related/relevant?

I would say there are three different categories of issues that we've faced:

  1. Code was timing-safe, but caused problems for this test due to our benchmarking strategy.
  2. Code was timing-unsafe due to unsafe usage/bug in crypto.timingSafeEqual.
  3. Code was timing-unsafe due to something other than crypto.timingSafeEqual.

If we're going to add info on timing-safe code to the docs, it should be to address issues in category (2) or (3). Documentation for category (2) is very important (e.g. "how to use crypto.timingSafeEqual safely"), and category (3) is useful but not as important/relevant ("how to write timing-safe code in JS").

I don't think we encountered any issues in category (2).

I have a very vague idea of how to prevent issues in category (3) based on what worked in this PR, but I don't think I know enough about these issues to write docs on how to prevent them. I don't want the docs to mislead people into thinking that their code is safe (because they followed instructions in the crypto docs) if it actually isn't.

tl;dr: The documentation can probably be improved, but I don't think it's urgent to do so, and it should probably be done by someone with more knowledge of V8 (presumably in a different PR).

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 3, 2016

Member

Maybe the thing to do for issues of type 3 is to put a short disclaimer indicating that it is still possible for other things in an application's code to cause it to be timing-unsafe even though this function is used, and just leave it at that for now. (We'll undoubtedly get questions about it, and we should expand on it as we can, but just having something like that there is probably enough to start with.)

Member

Trott commented Sep 3, 2016

Maybe the thing to do for issues of type 3 is to put a short disclaimer indicating that it is still possible for other things in an application's code to cause it to be timing-unsafe even though this function is used, and just leave it at that for now. (We'll undoubtedly get questions about it, and we should expand on it as we can, but just having something like that there is probably enough to start with.)

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Sep 3, 2016

Member

The docs in this PR are sufficient for now but can be expanded later as we get more collective experience with this kind of thing... (might make for a good conference talk someday too ;-) ...)

Member

jasnell commented Sep 3, 2016

The docs in this PR are sufficient for now but can be expanded later as we get more collective experience with this kind of thing... (might make for a good conference talk someday too ;-) ...)

doc/api/crypto.md
+
+`a` and `b` must both be `Buffer`s, and they must have the same length.
+
+**Note**: Use of `crypto.timingSafeEqual` does not guarantee that the *surrounding* code is timing-safe. Care should be taken to ensure that the surrounding code does not introduce timing vulnerabilities.

This comment has been minimized.

@jasnell

jasnell Sep 3, 2016

Member

Nit: can you add line breaks here? :-)

@jasnell

jasnell Sep 3, 2016

Member

Nit: can you add line breaks here? :-)

This comment has been minimized.

@not-an-aardvark

not-an-aardvark Sep 3, 2016

Member

Where should the line breaks be added? Do you mean between "...code is timing-safe." and "Care should..." ?

@not-an-aardvark

not-an-aardvark Sep 3, 2016

Member

Where should the line breaks be added? Do you mean between "...code is timing-safe." and "Care should..." ?

This comment has been minimized.

@lpinca

lpinca Sep 3, 2016

Member

@not-an-aardvark I think @jasnell means 80 chars per line.

@lpinca

lpinca Sep 3, 2016

Member

@not-an-aardvark I think @jasnell means 80 chars per line.

This comment has been minimized.

@not-an-aardvark

not-an-aardvark Sep 3, 2016

Member

Oh right, I forgot about that. Thanks @lpinca.

(Fixed)

@not-an-aardvark

not-an-aardvark Sep 3, 2016

Member

Oh right, I forgot about that. Thanks @lpinca.

(Fixed)

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Sep 3, 2016

Member

Great work @not-an-aardvark and @Trott ... LGTM with a nit

Member

jasnell commented Sep 3, 2016

Great work @not-an-aardvark and @Trott ... LGTM with a nit

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Sep 6, 2016

Member

There's no big rush, but I'd like to keep the process moving along on this PR, if possible. Is there anything I can do to advance it, or are we just waiting for people to review it at this point?

Member

not-an-aardvark commented Sep 6, 2016

There's no big rush, but I'd like to keep the process moving along on this PR, if possible. Is there anything I can do to advance it, or are we just waiting for people to review it at this point?

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Sep 6, 2016

Member

LGTM

And maybe /cc @AndreasMadsen and/or @fhinkel for reviews if they have the time? I wouldn’t hold the PR up about that but it might be good to get other math-y looks.

Member

addaleax commented Sep 6, 2016

LGTM

And maybe /cc @AndreasMadsen and/or @fhinkel for reviews if they have the time? I wouldn’t hold the PR up about that but it might be good to get other math-y looks.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Sep 7, 2016

Member

Let's give it another 24 hours at least.... and perhaps another dozen or so CI runs ;-) lol (kidding about the last bit).

Member

jasnell commented Sep 7, 2016

Let's give it another 24 hours at least.... and perhaps another dozen or so CI runs ;-) lol (kidding about the last bit).

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Sep 7, 2016

Member

Is it worth running the CI again now that the Raspberry Pi machines are no longer out of commission? If this test is going to break the build again for some reason, it would be better to find now rather than after the PR is merged.

Member

not-an-aardvark commented Sep 7, 2016

Is it worth running the CI again now that the Raspberry Pi machines are no longer out of commission? If this test is going to break the build again for some reason, it would be better to find now rather than after the PR is merged.

@Trott

This comment has been minimized.

Show comment
Hide comment
@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Sep 7, 2016

Member

ha! I started one at the exact moment @Trott did. Cancelled mine!

Member

jasnell commented Sep 7, 2016

ha! I started one at the exact moment @Trott did. Cancelled mine!

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 7, 2016

Member

@not-an-aardvark Can you get in touch with me out-of-band? I want to talk about the Collaborator onboarding stuff, but don't want to muddy up this issue with a bunch of irrelevant back-and-forth. Any of these work for me:

Or if you'd prefer some other mechanism to communicate, let me know.

Thanks!

Member

Trott commented Sep 7, 2016

@not-an-aardvark Can you get in touch with me out-of-band? I want to talk about the Collaborator onboarding stuff, but don't want to muddy up this issue with a bunch of irrelevant back-and-forth. Any of these work for me:

Or if you'd prefer some other mechanism to communicate, let me know.

Thanks!

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 7, 2016

Member

CI is all green except for the perma-yellow AIX, so I think this is good to land.

Member

Trott commented Sep 7, 2016

CI is all green except for the perma-yellow AIX, so I think this is good to land.

Trott added a commit to Trott/io.js that referenced this pull request Sep 7, 2016

crypto: add crypto.timingSafeEqual()
Reinstate crypto.timingSafeEqual() which was reverted due to test
issues. The flaky test issues are resolved in this new changeset.

PR-URL: nodejs#8304
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Sep 7, 2016

Member

Landed in 079accc

🎉

Thanks for persevering, @not-an-aardvark!

Member

Trott commented Sep 7, 2016

Landed in 079accc

🎉

Thanks for persevering, @not-an-aardvark!

@Trott Trott closed this Sep 7, 2016

@not-an-aardvark not-an-aardvark deleted the not-an-aardvark:timing-safe-equal-v2 branch Sep 7, 2016

@not-an-aardvark not-an-aardvark referenced this pull request Sep 8, 2016

Closed

test: make crypto.timingSafeEqual test less flaky #8456

3 of 3 tasks complete
@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Sep 9, 2016

Member

Sorry to be a party pooper but it seems the test is still flaky: https://ci.nodejs.org/job/node-test-commit-linux/5019/nodes=debian8-x86/consoleText

Member

bnoordhuis commented Sep 9, 2016

Sorry to be a party pooper but it seems the test is still flaky: https://ci.nodejs.org/job/node-test-commit-linux/5019/nodes=debian8-x86/consoleText

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Sep 9, 2016

Member

@bnoordhuis Yep, there is a PR open to fix this (see #8456).

Member

not-an-aardvark commented Sep 9, 2016

@bnoordhuis Yep, there is a PR open to fix this (see #8456).

Fishrock123 added a commit that referenced this pull request Sep 14, 2016

crypto: add crypto.timingSafeEqual()
Reinstate crypto.timingSafeEqual() which was reverted due to test
issues. The flaky test issues are resolved in this new changeset.

PR-URL: #8304
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>

Fishrock123 added a commit that referenced this pull request Sep 14, 2016

2016-09-14, Version 6.6.0 (Current)
Notable changes:

* crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark)
#8304
* events: Made the "max event listeners" memory leak warning more
accessible. (Anna Henningsen) #8298
* promises: Unhandled rejections now emit a process warning after the
first tick. (Benjamin Gruenbaum)
#8223
* repl: Added auto alignment for `.editor` mode. (Prince J Wesley)
#8241
* util: Some functionality has been added to `util.inspect()`:
- Returning `this` from a custom inspect function now works. (Anna
Henningsen) #8174
- Added support for Symbol-based custom inspection methods. (Anna
Henningsen) #8174

Refs: #8428
Refs: #8457
PR-URL: #8466

Fishrock123 added a commit to Fishrock123/node that referenced this pull request Sep 15, 2016

2016-09-14, Version 6.6.0 (Current)
Notable changes:

* crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark)
nodejs#8304
* events: Made the "max event listeners" memory leak warning more
accessible. (Anna Henningsen) nodejs#8298
* promises: Unhandled rejections now emit a process warning after the
first tick. (Benjamin Gruenbaum)
nodejs#8223
* repl: Added auto alignment for `.editor` mode. (Prince J Wesley)
nodejs#8241
* util: Some functionality has been added to `util.inspect()`:
- Returning `this` from a custom inspect function now works. (Anna
Henningsen) nodejs#8174
- Added support for Symbol-based custom inspection methods. (Anna
Henningsen) nodejs#8174

Refs: nodejs#8428
Refs: nodejs#8457
PR-URL: nodejs#8466

@ChALkeR ChALkeR referenced this pull request in hapijs/cryptiles Sep 15, 2016

Closed

Use crypto.timingSafeEqual for fixedTimeComparison #24

imyller added a commit to imyller/meta-nodejs that referenced this pull request Sep 15, 2016

2016-09-14, Version 6.6.0 (Current)
    Notable changes:

    * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark)
    nodejs/node#8304
    * events: Made the "max event listeners" memory leak warning more
    accessible. (Anna Henningsen) nodejs/node#8298
    * promises: Unhandled rejections now emit a process warning after the
    first tick. (Benjamin Gruenbaum)
    nodejs/node#8223
    * repl: Added auto alignment for `.editor` mode. (Prince J Wesley)
    nodejs/node#8241
    * util: Some functionality has been added to `util.inspect()`:
    - Returning `this` from a custom inspect function now works. (Anna
    Henningsen) nodejs/node#8174
    - Added support for Symbol-based custom inspection methods. (Anna
    Henningsen) nodejs/node#8174

Signed-off-by: Ilkka Myller <ilkka.myller@nodefield.com>

imyller added a commit to imyller/meta-nodejs that referenced this pull request Sep 15, 2016

2016-09-14, Version 6.6.0 (Current)
    Notable changes:

    * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark)
    nodejs/node#8304
    * events: Made the "max event listeners" memory leak warning more
    accessible. (Anna Henningsen) nodejs/node#8298
    * promises: Unhandled rejections now emit a process warning after the
    first tick. (Benjamin Gruenbaum)
    nodejs/node#8223
    * repl: Added auto alignment for `.editor` mode. (Prince J Wesley)
    nodejs/node#8241
    * util: Some functionality has been added to `util.inspect()`:
    - Returning `this` from a custom inspect function now works. (Anna
    Henningsen) nodejs/node#8174
    - Added support for Symbol-based custom inspection methods. (Anna
    Henningsen) nodejs/node#8174

Signed-off-by: Ilkka Myller <ilkka.myller@nodefield.com>

@madarche madarche referenced this pull request Sep 26, 2016

Closed

Document crypto.timingSafeEqual() added in v6.6.0 #8796

2 of 2 tasks complete

jasnell added a commit that referenced this pull request Sep 27, 2016

doc: add added: info for crypto.timingSafeEqual()
crypto.timingSafeEqual() has been added in v6.6.0 cf. #8304

This commit adds the metadata that will display
"Added in: v6.6.0" and that can later be checked on
https://nodejs.org/api/crypto.html#crypto_crypto_timingsafeequal_a_b

PR-URL: #8796
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Teddy Katz <teddy.katz@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>

jasnell added a commit that referenced this pull request Sep 29, 2016

doc: add added: info for crypto.timingSafeEqual()
crypto.timingSafeEqual() has been added in v6.6.0 cf. #8304

This commit adds the metadata that will display
"Added in: v6.6.0" and that can later be checked on
https://nodejs.org/api/crypto.html#crypto_crypto_timingsafeequal_a_b

PR-URL: #8796
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Teddy Katz <teddy.katz@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>

Fishrock123 added a commit that referenced this pull request Oct 11, 2016

doc: add added: info for crypto.timingSafeEqual()
crypto.timingSafeEqual() has been added in v6.6.0 cf. #8304

This commit adds the metadata that will display
"Added in: v6.6.0" and that can later be checked on
https://nodejs.org/api/crypto.html#crypto_crypto_timingsafeequal_a_b

PR-URL: #8796
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Teddy Katz <teddy.katz@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment