-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
lib: remove useless input parameters and make 'digest' clear in the doc #22858
Conversation
I think this changes the behavior if |
Since in the doc, we didn't make 'digest' so clear (allowing which types it takes and what error it will throw out...ect). I'd also take this :) |
That is technically correct... Weird how For the future: The first word of the commit message title should not be capitalized, see our guidelines. |
doc/api/crypto.md
Outdated
@@ -1791,6 +1791,11 @@ but will take a longer amount of time to complete. | |||
The `salt` should be as unique as possible. It is recommended that a salt is | |||
random and at least 16 bytes long. See [NIST SP 800-132][] for details. | |||
|
|||
The `digest` should either be a string value or null: | |||
- If it's null, `sha1` will be the default one |
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.
String literals should be enclosed in single quotes: 'sha1'
. Also the two instances of null above should be styled as null
.
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'd prefer not to document this at all since the behavior should have been EOL years ago, see #22861.
doc/api/crypto.md
Outdated
@@ -1791,6 +1791,11 @@ but will take a longer amount of time to complete. | |||
The `salt` should be as unique as possible. It is recommended that a salt is | |||
random and at least 16 bytes long. See [NIST SP 800-132][] for details. | |||
|
|||
The `digest` should either be a string value or null: | |||
- If it's null, `sha1` will be the default one | |||
- For other type values, An error `ERR_INVALID_ARG_TYPE` |
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 don't think we need to document this explicitly.
doc/api/crypto.md
Outdated
@@ -1791,6 +1791,11 @@ but will take a longer amount of time to complete. | |||
The `salt` should be as unique as possible. It is recommended that a salt is | |||
random and at least 16 bytes long. See [NIST SP 800-132][] for details. | |||
|
|||
The `digest` should either be a string value or null: |
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 think we can just shorten this to just mention that if digest
is null
, then 'sha1'
is used, or perhaps include that explanation earlier in the function description where digest
is first mentioned.
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.
Take this adive! :)
On the one hand, it tells the truth, though we've missed that by accident.
On the other hand, this has given a good explaination to tell users that this value of null is deprecated since v11.
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.
What I was mainly getting at about this line is that the part about needing to be a string value is unnecessary as earlier in the description it's noted that digest
should be an HMAC digest algorithm, which implicitly means a string value.
@mscdex & @tniessen:Having reviewed all of your suggestions. It seems we'd better include this usage of digest (though it's puzzling) in our doc, BUT just mention that this will be deprecated in v11.x. I've put the declaration to the top of the function as the explainations We've got such a sample before, see : https://nodejs.org/dist/latest-v8.x/docs/api/events.html#events_error_events (Note, however, that the domain module has been deprecated.) |
I would prefer to keep that very concise, maybe something like "If the
We usually don't explicitely reference future Node.js versions. You can write something like "will be deprecated in a future Node.js version" though, but please keep it short. |
doc/api/crypto.md
Outdated
@@ -1784,6 +1784,12 @@ otherwise `err` will be `null`. By default, the successfully generated | |||
`derivedKey` will be passed to the callback as a [`Buffer`][]. An error will be | |||
thrown if any of the input arguments specify invalid values or types. | |||
|
|||
The `digest` should either be a string value or null: | |||
- if it's null, `sha1` will be the default one |
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.
String literals should be enclosed in single quotes: 'sha1'
. Also the two instances of null above should be styled as null
.
doc/api/crypto.md
Outdated
The `digest` should either be a string value or null: | ||
- if it's null, `sha1` will be the default one | ||
(this will be deprecated since v11.x) | ||
- for other type values, An error `ERR_INVALID_ARG_TYPE` |
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 don't think we need to document this behavior explicitly.
doc/api/crypto.md
Outdated
@@ -1784,6 +1784,12 @@ otherwise `err` will be `null`. By default, the successfully generated | |||
`derivedKey` will be passed to the callback as a [`Buffer`][]. An error will be | |||
thrown if any of the input arguments specify invalid values or types. | |||
|
|||
The `digest` should either be a string value or null: |
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 still believe that mentioning 'string value' here is redundant since it is stated earlier in the function description that digest
is an HMAC digest algorithm, which implicitly means a string value.
OK. I'll just keep that very concise, according to what @tniessen's suggestion's. |
(Any reason not to immediately introduce a Documentation-only deprecation? /cc @tniessen Is that already happening in another PR? If so, presumably the docs are updated there already and so maybe this isn't necessary, except perhaps for backporting to older versions or something?) |
1) Remove 'callback' in 'check' function, because we don't check or use that directly. 2) Adjust the orders of codes in 'pbkdf2' to have a quick check whether the callback is a function or not instead of using it into the 'check' method. 3) Make 'digest' more clear in doc.
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.
Still LGTM.
Thanks for updating your PR so often! Pre-land CI: https://ci.nodejs.org/job/node-test-pull-request/17238/ |
Only failure seems to be an OS / HW problem, see nodejs/build#1499. Landed in ba0b4e4, thank you @Maledong! 🎉 |
1) Remove 'callback' in 'check' function, because we don't check or use that directly. 2) Make 'digest' clearer in the documentation. PR-URL: #22858 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Thanks all! |
1) Remove 'callback' in 'check' function, because we don't check or use that directly. 2) Make 'digest' clearer in the documentation. PR-URL: #22858 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
1) Remove 'callback' in 'check' function, because we don't check or use that directly. 2) Make 'digest' clearer in the documentation. PR-URL: #22858 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Remove 'callback' in 'check' function, because we don't check or use
that directly.
Adjust the orders of codes in 'pbkdf2' to have a quick check whether
the callback is a function or not instead of using it into the 'check'
method.
Add explainations to 'digest' in the doc.
make -j4 test
(UNIX), orvcbuild test
(Windows) passes