-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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 better scrypt option aliases #21525
Conversation
lib/internal/crypto/scrypt.js
Outdated
@@ -82,10 +82,16 @@ function check(password, salt, keylen, options, callback) { | |||
if (options && options !== defaults) { | |||
if (options.hasOwnProperty('N')) | |||
N = validateInt32(options.N, 'N', 0, INT_MAX); | |||
if (options.hasOwnProperty('cost')) |
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.
If we do go the route of adding these aliases, I'd prefer if these were else if
s, and the priority were documented and tested. Otherwise, the priority becomes an implementation detail that could subtly break in the future. Throwing is another option if someone were to provide N
and cost
, but that might be overkill.
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.
Perhaps process.emitWarning()
if both are provided would be a softer nudge?
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.
I agree that a test for the priority would be a good addition here. Will sign off with that added.
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.
doc/api/crypto.md
Outdated
- `r` {number} Block size parameter. **Default:** `8`. | ||
- `p` {number} Parallelization parameter. **Default:** `1`. | ||
- `cost` {number} CPU/memory cost parameter. Must be a power of two greater | ||
than one. **Default:** `16384`. |
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.
Such indentation produces false code blocks in HTML version.
maxmem
case below will be fixed in #21500, cost
case seems to need fixing here.
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.
@vsemozhetbyt Thanks for pointing that out, done!
doc/api/crypto.md
Outdated
- `r` {number} Block size parameter. **Default:** `8`. | ||
- `p` {number} Parallelization parameter. **Default:** `1`. | ||
- `cost` {number} CPU/memory cost parameter. Must be a power of two greater | ||
than one. **Default:** `16384`. |
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.
Ditto.
lib/internal/crypto/scrypt.js
Outdated
@@ -82,10 +82,16 @@ function check(password, salt, keylen, options, callback) { | |||
if (options && options !== defaults) { | |||
if (options.hasOwnProperty('N')) | |||
N = validateInt32(options.N, 'N', 0, INT_MAX); | |||
if (options.hasOwnProperty('cost')) |
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.
I agree that a test for the priority would be a good addition here. Will sign off with that added.
d11c385
to
f4f7d6b
Compare
Thanks for the PR: it would help me. I always had trouble with these non-readable option names (already with |
ping @jasnell :) |
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.
Have you considered something like this instead:
const { kCost, kBlockSize, kParallelization } = crypto.constants;
// …
scrypt(..., {
[kCost]: 16,
[kParallelization]: 1,
[kBlockSize]: 1
});
This is similarly readable but avoids the maneuver we have to do with regards to option handling.
lib/internal/crypto/scrypt.js
Outdated
@@ -80,12 +80,25 @@ function check(password, salt, keylen, options, callback) { | |||
|
|||
let { N, r, p, maxmem } = defaults; | |||
if (options && options !== defaults) { | |||
if (options.hasOwnProperty('N')) | |||
let has_N, has_r, has_p; | |||
if (has_N = options.hasOwnProperty('N')) |
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.
I know the hasOwnProperty
has already been there, but we should really use undefined
as a measure of if an option was set, to be consistent with the rest of the API surface and to prevent Object.create(null)
from breaking 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.
@TimothyGu Done!
f4f7d6b
to
fad284e
Compare
Can you explain how your suggestion would work? |
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.
sorry for the delay, was on vacation :-)
Make parameter names available in a human-readable way, for more accessible/self-documenting usage of the `scrypt` functions. This implements a review comment from the original PR that has not been addressed. Refs: nodejs#20816 (comment)
fad284e
to
83800fa
Compare
AIX benchmark failures seem inexplicable. Maybe something's up on the host such that it can't launch subprocesses at the moment? Anyway, here's a Resume Build: https://ci.nodejs.org/job/node-test-pull-request/15899/ UPDATE: It's green. |
We have a green CI and one approval. This can technically land, but would be great if someone from @nodejs/crypto could give it a quick look. |
@addaleax Sorry I missed the notification on this thread. My proposal was to export three string-valued constants from |
@TimothyGu How strongly do you feel about that? It seems like that would feel a bit less natural here… |
@addaleax Not very, just trying to offer an alternative here. |
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.
LGTM :)
Landed in e9b22e9 |
Make parameter names available in a human-readable way, for more accessible/self-documenting usage of the `scrypt` functions. This implements a review comment from the original PR that has not been addressed. Refs: #20816 (comment) PR-URL: #21525 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Depends on #21782 to land on |
Make parameter names available in a human-readable way, for more accessible/self-documenting usage of the `scrypt` functions. This implements a review comment from the original PR that has not been addressed. Refs: #20816 (comment) PR-URL: #21525 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Make parameter names available in a human-readable way, for more accessible/self-documenting usage of the `scrypt` functions. This implements a review comment from the original PR that has not been addressed. Refs: #20816 (comment) PR-URL: #21525 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
It is confusing to have both ERR_CRYPTO_SCRYPT_INVALID_PARAMETER and ERR_CRYPTO_INVALID_SCRYPT_PARAMS. The former was the original error code, added in 371103d, but parameter validation gradually changed and now produces ERR_CRYPTO_INVALID_SCRYPT_PARAMS for all parameter validation errors coming from OpenSSL, as well as different error codes for validation errors coming from JavaScript. The only remaining use of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER is in the validation logic that ensures that no two synonymous options were passed. We already have an error code for that particular case, ERR_INCOMPATIBLE_OPTION_PAIR, so replace these last instances of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER with that error code and remove ERR_CRYPTO_SCRYPT_INVALID_PARAMETER. If there ever is need again for such an error code, we can just use ERR_CRYPTO_INVALID_SCRYPT_PARAMS. Refs: nodejs#35093 Refs: nodejs#21525 Refs: nodejs#20816
It is confusing to have both ERR_CRYPTO_SCRYPT_INVALID_PARAMETER and ERR_CRYPTO_INVALID_SCRYPT_PARAMS. The former was the original error code, added in 371103d, but parameter validation gradually changed and now produces ERR_CRYPTO_INVALID_SCRYPT_PARAMS for all parameter validation errors coming from OpenSSL, as well as different error codes for validation errors coming from JavaScript. The only remaining use of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER is in the validation logic that ensures that no two synonymous options were passed. We already have an error code for that particular case, ERR_INCOMPATIBLE_OPTION_PAIR, so replace these last instances of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER with that error code and remove ERR_CRYPTO_SCRYPT_INVALID_PARAMETER. If there ever is need again for such an error code, we can just use ERR_CRYPTO_INVALID_SCRYPT_PARAMS. Refs: #35093 Refs: #21525 Refs: #20816 PR-URL: #53305 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
It is confusing to have both ERR_CRYPTO_SCRYPT_INVALID_PARAMETER and ERR_CRYPTO_INVALID_SCRYPT_PARAMS. The former was the original error code, added in 371103d, but parameter validation gradually changed and now produces ERR_CRYPTO_INVALID_SCRYPT_PARAMS for all parameter validation errors coming from OpenSSL, as well as different error codes for validation errors coming from JavaScript. The only remaining use of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER is in the validation logic that ensures that no two synonymous options were passed. We already have an error code for that particular case, ERR_INCOMPATIBLE_OPTION_PAIR, so replace these last instances of ERR_CRYPTO_SCRYPT_INVALID_PARAMETER with that error code and remove ERR_CRYPTO_SCRYPT_INVALID_PARAMETER. If there ever is need again for such an error code, we can just use ERR_CRYPTO_INVALID_SCRYPT_PARAMS. Refs: nodejs#35093 Refs: nodejs#21525 Refs: nodejs#20816 PR-URL: nodejs#53305 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Make parameter names available in a human-readable way, for
more accessible/self-documenting usage of the
scrypt
functions.This implements a review comment from the original PR that has
not been addressed.
Refs: #20816 (comment)
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes