-
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
crypto: reconcile oneshot sign/verify sync and async implementations #37816
Conversation
a1de71c
to
bbc1058
Compare
bbc1058
to
e82cbd1
Compare
This comment has been minimized.
This comment has been minimized.
cc @nodejs/crypto |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
9655b0f
to
b2f8ba7
Compare
145ce72
to
c1b1f4d
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
96c63ed
to
dfdf742
Compare
This comment has been minimized.
This comment has been minimized.
dfdf742
to
20ee199
Compare
@panva @danbev Re thread-safety:
Thinking further...
|
I'm aware of these and I saw that I think the suggestions here are good and worth pursuing. What I would like is we get the OpenSSL 3.0 CI job in place before we start this work. It was time consuming to get all the tests to pass against OpenSSL 3.0 and the threading issue was only one of them. At the moment any changes to crypto could break the tests and I have to go chasing them down afterwards. |
@danbev are you tracking the places where parallel performance may have been affected by these openssl3 related changes? If not we have to look at all crypto async APIs (that's for sure this one here and all of webcrypto) and bench them with the same keyobject vs unique keyobjects, before and after the changes were put in place and figure out a way forward if performance was impacted like this API here. Ideally this would've been done before the changes landed in a release. |
Anywhere an EVP_PKEY is used from multiple threads. There was an assumption that this was not required with versions prior to OpenSSL 3.0, but there was never such a guarantee from OpenSSL about this as far as I understand it. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@danbev @tniessen I've added a parallel libuv threaded test and the only failure with openssl3 is the one from #38136. Can I assume the lock is therefore not necessary and this can proceed? |
This comment has been minimized.
This comment has been minimized.
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.
Excellent 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.
lgtm
Why is this identified as semver-major? |
It isn't anymore. At first it looked like there were going to be minor differences. |
PR-URL: #37816 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Landed in e8cb644 |
This reconciles the crypto.sign and crypto.verify C++ implementation when running with or without a callback.