-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto: add sync methods, deprecate optional callbacks #632
crypto: add sync methods, deprecate optional callbacks #632
Conversation
|
||
exports.rng = exports.prng = randomBytes; | ||
exports.rng = util.deprecateSync(randomBytes, '`crypto.rng(size)` is deprecated. Please us `crypto.rngSync(size)` instead.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
“Please us” → “Please use”
// except it only warns if the last argument is not a callback function. | ||
exports.deprecateSync = function(fn, msg) { | ||
// Allow for deprecating things in the process of starting up. | ||
if (isUndefined(global.process)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switch away from isUndefined
please, see 6ac8bcd
.
removed all those stupid utilities :D |
// Mark that the synchronous version of a function is deprecated. | ||
// This is essentially the same as `exports.deprecate()`, | ||
// except it only warns if the last argument is not a callback function. | ||
exports.deprecateSync = function(fn, msg) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make it _private
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't that mean deprecate()
should be private too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the idea is that if we don't have intention of making function public (and documenting it), it should be marked as private. Since it's used only in crypto I'm not even sure there is a point in defining it in utils.
@jonathanong Can you run |
seems fine to me:
|
@jonathanong run |
lines too long :( will fix later |
okay it asks for 4 space indents, which is different than other stuff. pretty lost. lint passes though. |
to be fair, i don't really want to edit any current tests. i only want to make new ones. i'm okay with disallowing the use of callbacks with the what would you like to test specifically? whether the deprecation messages gets logged? the sync APIs? |
I understand about editing current tests; I've seen plenty of deprecated stuff in the tests anyways. I guess that makes sense too about the I'd like to get this in before 2.0.0 (#1061) btw so that we could potentially remove the old functionality in 3.0.0. |
@brendanashworth ping |
besides my comments, I think the only thing necessary now would be the doc updates, and even then, we just need |
oops. i forgot to commit the super simple test i added. also, added docs. amend and squash at will! |
may conceivably block is right after boot, when the whole system is still | ||
low on entropy. | ||
|
||
NOTE: The synchronous API for this method is deprecated - please use `crypto.randomBytesSync(size)` instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is over 80 characters, could you wrap it?
Minus the comment, this LGTM now. @iojs/crypto? |
crypto.randomBytes(256, function(ex, buf) { | ||
if (ex) throw ex; | ||
console.log('Have %d bytes of random data: %s', buf.length, buf); | ||
}); | ||
|
||
// sync | ||
NOTE: This will block if there is insufficient entropy, although it should |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure about this? ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no. i didn't change any of the copy. it just shows up in the diff because code moved around.
I'm fine with the change, but it is rather questionable to me if we need the async version in most of the cases. Could anyone please do the benchmarks for a small amount of data (like 64-128 bytes)? |
would be great if there's no need for the async version! |
Using this benchmark, macbook pro ~2013: diff --git a/benchmark/crypto/random-bytes.js b/benchmark/crypto/random-bytes.js
new file mode 100644
index 0000000..452cd8a
--- /dev/null
+++ b/benchmark/crypto/random-bytes.js
@@ -0,0 +1,19 @@
+var common = require('../common');
+var randomBytes = require('crypto').randomBytes;
+var bench = common.createBenchmark(main, {
+ n: [1e5],
+ len: [32, 64, 128, 256, 1024]
+});
+
+function main(conf) {
+ var len = conf.len | 0;
+ var n = conf.n | 0;
+
+ bench.start();
+
+ for (var i = 0; i < n; i++) {
+ randomBytes(len);
+ }
+
+ bench.end(n);
+} I'm getting numbers like this:
|
As per request [here](nodejs#632 (comment)).
tl;dr: async randomBytes is nowhere near necessary on a macbook pro, probably unnecessary for anything but integrated hardware |
i fine with deprecating all the "random" APIs in favor of just a synchronous |
See this code comment: randomness is usually but not always immediate. A secondary issue is that it's computationally expensive; generating a lot of randomness, even when there is enough entropy, will block the event loop for some time. Semi-related: nodejs/node-v0.x-archive#7338 |
|
||
## crypto.randomBytesSync(size) | ||
|
||
A synchronous version of `crypto.randomBytes(size)`. Usage: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It kinda gives me a feeling that there are more than one synchronous implementations and this is one of them.
Hmmm, can we defer merging this for some more time, if that's okay? I would like to properly go through the |
Verify that passing a non-number will throw and that the argument is returned on success. PR-URL: #2121 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
On windows, there's no need to continue with the msbuild process (signing, whatnot) when we only want to clean the project. PR-URL: #2127 Reviewed-By: Alexis Campailla <alexis@janeasystems.com>
@thefourtheye Sure, it can wait a little bit. |
If the proxy objects don't have a valid `hasOwnPropertyNames` trap, REPL crashes with a `TypeError`, as per the bug report #2119 > var proxy = Proxy.create({ fix: function() { return {}; } }); undefined > proxy.<tab> TypeError: Proxy handler #<Object> has no 'getOwnPropertyNames' trap at Function.getOwnPropertyNames (native) at repl.js:644:40 at REPLServer.defaultEval (repl.js:169:5) at bound (domain.js:254:14) at REPLServer.runBound [as eval] (domain.js:267:12) at REPLServer.complete (repl.js:639:14) at REPLServer.complete [as completer] (repl.js:207:10) at REPLServer.Interface._tabComplete (readline.js:377:8) at REPLServer.Interface._ttyWrite (readline.js:845:14) at ReadStream.onkeypress (readline.js:105:10) This patch traps the error thrown and suppresses it. PR-URL: #2120 Fixes: #2119 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com>
configure was getting called twice. We also erroneously introduced support for VS2010, and were picking 2010 before other versions. PR-URL: #2131 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Adding a single rule to be called from Jenkins. Jenkins jobs typically call: python ./configure make -j $(getconf _NPROCESSORS_ONLN) make test-ci After this change, we can have Jenkins call: make run-ci -j $(getconf _NPROCESSORS_ONLN) This allows us to customize how we call configure for different repos or branches (e.g. joyent\node). PR-URL: #2134 Reviewed-By: Ryan Graham <r.m.graham@gmail.com> Reviewed-By: Johan Bergström <bugs@bergstroem.nu> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
When the listener was truthy but NOT a function, fs.watchFile would throw an error through the EventEmitter. This caused a problem because it would only be thrown after the listener was started, which left the listener on. There should be no backwards compatability issues because the error was always thrown, just in a different manner. Also adds tests for this and other basic functionality. PR-URL: #2093 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When fs.watchFile encounters an ENOENT error, it invokes the given callback with some error data. This caused an issue as it was different behaviour than Node v0.10. Instead of changing this behaviour, document it and add a test. Ref: #1745 Ref: #2028 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> PR-URL: #2093
- This makes v8 add .trace_function_info to the serialized form of snapshots from v8::HeapSnapshot::Serialize - .trace_funciton_info combined with .trace_node in snapshots tells the JS location that allocated a specific object PR-URL: #2135 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
`emitKeys` is a generator which emits `keypress` events in an infinite loop. But if `keypress` event handler throws, the error stops the loop, leaving generator in a broken state. So this patch restarts the generator when an error occures. PR-URL: #2107 Reviewed-By: Christopher Monsanto <chris@monsan.to> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Re-use `assertPath()` when asserting path argument types in `join()` as throughout the rest of the `path` module. This also ensures the same error message generated for posix as for win32. PR-URL: #2159 Reviewed-By: Roman Reiss <me@silverwind.io>
A persistent failure on OS X 10.11 uncovered a inproperly cleaned up temp directory in this test. This changes the mkdirSync call to clean up properly in case it throws. PR-URL: #2164 Reviewed-By: Evan Lucas <evanlucas@me.com>
Fixes the arguments comments for execFileSync and other related minor inconsistencies in commented arguments in the same file. PR-URL: #2161 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
'`crypto.pseudoRandomBytes()` is deprecated. ' + | ||
'Please use `crypto.randomBytes()` instead.'); | ||
|
||
exports.rng = util._deprecateSync(randomBytes, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of introducing a new deprecation method, you can simply do do the callback check and deprecation message in node_crypto.cc
' RandomBytes
function. @silverwind, please correct me if I am wrong.
@jonathanong if you could rebase your branch against current master, I'll provide a .patch for you to fix the deprecation. |
oh shit. this is a PR against v1.x. i rebased it against master. now the diff looks terrible. |
what do you want to do? cherry-pick the commits? open a new PR against |
Did you miss a |
@silverwind no it's just against the wrong branch. i think i opened this before you guys moved to |
You may be able to fix it with https://github.com/github/hub#git-pull-request monkeying, but it's easier to just open a new PR and reference it back. |
for #5. rebased and reopened from #189 (because i forgot about this PR when deleting my fork...).
.randomBytes()
.pseudoRandomBytes()
as now it's just an alias for.randomBytes()
. another option is to ignore any deprecation messages forpseudo*
, but I'm not adding a*Sync
for method for them..deprecateSync()
utilityTODO:
Questions:
sync
version. after all this is about the public API. is that something you guys want?.randomBytes()
and.pseudoRandomBytes()
. were there others?