-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Define the deriveBits length parameter as optional #30667
Define the deriveBits length parameter as optional #30667
Conversation
EWS run on previous version of this PR (hash 86047c8) |
86047c8
to
7fd6e2a
Compare
EWS run on previous version of this PR (hash 7fd6e2a) |
7fd6e2a
to
b91c638
Compare
EWS run on previous version of this PR (hash b91c638) |
@@ -85,7 +85,7 @@ | |||
return Promise.resolve().then(function(result) { | |||
// P-256 | |||
return Promise.all([ | |||
deriveBits(P256, 0, 256), |
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.
Nit: While you are at it, how about add:
deriveBits(P256, 0)
also and such to all the cases so that they also get tested here.
I am aware that such tests are in wpt, but this will read better in itself.
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.
Makes sense. As a matter of fact I've been thinking on porting those tests to WPT; anyway, this will be a follow up patch, so I'll add the new test cases here meanwhile.
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.
Now that I think about it, it's unfortunate the deriveBits utility function defines the "expectedLength" as the last parameter. This makes more complex to add test cases for the "omitted" case.
Do you think it's worth to do a refactoring of the test because of this ?
{ | ||
if (!length || length % 8) { | ||
if (!length || !(*length) || *length % 8) { |
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.
:rant
This thing is super onfortunate :D
:end-rant
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.
yeah, I'd rather have *length != 0
but it seems the style-checker complains about that.
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.
Looks good to me.
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.
Could you beef up the commit message and explain why it is ok to change length=0 behavior?
AIUI from the GitHub issue, usage is very low so this is likely ok but it would be good that you confirm this.
And maybe the length=0 change should be done in a separate PR in case of regression.
@@ -49,7 +49,7 @@ PASS SubtleCrypto interface: operation verify(AlgorithmIdentifier, CryptoKey, Bu | |||
PASS SubtleCrypto interface: operation digest(AlgorithmIdentifier, BufferSource) | |||
PASS SubtleCrypto interface: operation generateKey(AlgorithmIdentifier, boolean, sequence<KeyUsage>) | |||
PASS SubtleCrypto interface: operation deriveKey(AlgorithmIdentifier, CryptoKey, AlgorithmIdentifier, boolean, sequence<KeyUsage>) | |||
PASS SubtleCrypto interface: operation deriveBits(AlgorithmIdentifier, CryptoKey, unsigned long) | |||
FAIL SubtleCrypto interface: operation deriveBits(AlgorithmIdentifier, CryptoKey, unsigned long) assert_equals: property has wrong .length expected 3 but got 2 |
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.
Can we resync that test?
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.
Done
PASS X25519 derivation with 256 as 'length' parameter | ||
FAIL X25519 derivation with 0 as 'length' parameter assert_array_equals: Derived bits do not match the expected result. lengths differ, expected array object "" length 0, got object "63,245,136,2,149,247,97,118,8,143,137,228,61,254,190,126,161,149,0,8" length 32 | ||
PASS X25519 derivation with 0 as 'length' parameter |
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 it is probably ok to both make the parameter optional and change the behavior for length 0.
But maybe it would be a bit safer to split in two.
@javifernandez, how confident are you with this change of behavior?
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 there is consensus in the PR about pursuing the same behavior for the four algorithms when length=0 is used, so that it returns an empty string. However, I think there is a bit of a mess in terms of interoperability regarding this operation:
Chrome already returns an empty string for X25519, while WebKit doesn´t. However, Chrome doesn't do the same with HKDF (although it does for PBKDF2), while WebKit does.
Chrome also asked to do the length=0 change, for its affected algorithms, in a separate change, so I'll do the same for WebKit.
b91c638
to
3d5c213
Compare
EWS run on previous version of this PR (hash 3d5c213) |
3d5c213
to
5db8323
Compare
EWS run on current version of this PR (hash 5db8323) |
The failures in the gtk-wk2 bot seems unrelated to this change. So I'll try the merge queue now. |
https://bugs.webkit.org/show_bug.cgi?id=276394 Reviewed by Youenn Fablet and Nitin Mahendru. The PR#345 [1] to the WebCryptoAPI spec defines now the 'length' parameter as optional, defaulting to 'null'. This change tries to solve a long-standing interoperability issue in the deriveBits operation. This patch implements the required changes in the IDL so that the 'length' parameter is declared as optional, with 'null' as default value when omitted. The affected algorithms (ECDH, HKDF, PBKDF2 and X25519) are adapted to the parameter's new type. The PR#43400 [2] defined tests for the new behavior of the afected algorithms, which they all pass now. [1] w3c/webcrypto#345 [2] web-platform-tests/wpt#43400 * LayoutTests/crypto/subtle/derive-bits-malformed-parameters-expected.txt: * LayoutTests/crypto/subtle/derive-bits-malformed-parameters.html: * LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/derive_bits_keys/derived_bits_length.https.any-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/derive_bits_keys/derived_bits_length.https.any.worker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/idlharness.https.any-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/WebCryptoAPI/idlharness.https.any.worker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/interfaces/WebCryptoAPI.idl: * Source/WebCore/crypto/CryptoAlgorithm.cpp: (WebCore::CryptoAlgorithm::deriveBits): * Source/WebCore/crypto/CryptoAlgorithm.h: * Source/WebCore/crypto/SubtleCrypto.cpp: (WebCore::SubtleCrypto::deriveKey): (WebCore::SubtleCrypto::deriveBits): * Source/WebCore/crypto/SubtleCrypto.h: * Source/WebCore/crypto/SubtleCrypto.idl: * Source/WebCore/crypto/algorithms/CryptoAlgorithmECDH.cpp: (WebCore::CryptoAlgorithmECDH::deriveBits): * Source/WebCore/crypto/algorithms/CryptoAlgorithmECDH.h: * Source/WebCore/crypto/algorithms/CryptoAlgorithmHKDF.cpp: (WebCore::CryptoAlgorithmHKDF::deriveBits): * Source/WebCore/crypto/algorithms/CryptoAlgorithmHKDF.h: * Source/WebCore/crypto/algorithms/CryptoAlgorithmPBKDF2.cpp: (WebCore::CryptoAlgorithmPBKDF2::deriveBits): * Source/WebCore/crypto/algorithms/CryptoAlgorithmPBKDF2.h: * Source/WebCore/crypto/algorithms/CryptoAlgorithmX25519.cpp: (WebCore::CryptoAlgorithmX25519::deriveBits): * Source/WebCore/crypto/algorithms/CryptoAlgorithmX25519.h: Canonical link: https://commits.webkit.org/281240@main
5db8323
to
9586d3d
Compare
Committed 281240@main (9586d3d): https://commits.webkit.org/281240@main Reviewed commits have been landed. Closing PR #30667 and removing active labels. |
9586d3d
5db8323
🧪 gtk-wk2🧪 api-gtk