GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — crypto: pass all WebCryptoAPI WPTs by panva · Pull Request #43656 · nodejs/node Conversation
|
|
Review requested:
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
716caf7 to
5b47b67
Compare
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Some drive-by comments. I'm surprised WPT expects zero-sized keys to do something meaningful.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
@nodejs/testing how can I increase the test timeout for |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
@nodejs/testing please take a look at my previous question #43656 (comment) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@panva Is the issue with the timeout set in Lines 945 to 949 in 3aec7da
If that's the timeout you are referring to, you can perhaps do something similar to what was done for |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Thank you @Trott, I've just pushed an inclusion of |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@Trott the timeout change has definitely helped on most configurations, and github CI, but node-test-commit-freebsd failed the same way two times in a row, the webcrypto job is not even logged |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
@Trott Similar to FreeBSD before, the |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
@panva I've increased the timeout to 12 minutes. nodejs/build#3001 I didn't do it before resuming the build 5 minutes ago, though, so if that build fails, use Resume Build on it and it should run again with the 12-minute limit instead. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
This is really great work.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
❗ support for zero-length secret KeyObject
I am not happy about this, but I also don't see a way around it.
❗ workaround for openssl EVP_PKEY_derive HKDF not playing nice with zero-length IKM
It might be worth considering allowing this only through Web Crypto, not through node crypto. On the other hand, it seems to go through createSecretKey in both cases, so that might not be pretty.
I really don't like supporting things that OpenSSL does not support, but at least it's somewhat simple here.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| } | ||
|
|
||
| std::shared_ptr<KeyObjectData> KeyObjectData::CreateSecret(ByteSource key) { | ||
| CHECK(key); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
We might need to verify that no other uses of KeyObjectData (and related structures) assume that the stored pointer is not nullptr. Otherwise, we might end up with aborts/crashes if someone constructs 0-length keys and uses them with other APIs.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Why is a zero length buffer key data treated as a nullptr? I would like to keep the check here but I don't understand the C++ keyobject implementation enough.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
It might be because malloc(len) for len = 0 is allowed to return a nullptr. The standard only requires the returned pointer to be valid for len bytes, which nullptr fulfills when len = 0.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Do you have a suggestion that would allow us to keep this check?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| if (!EVP_PKEY_CTX_hkdf_mode(ctx.get(), | ||
| EVP_PKEY_HKDEF_MODE_EXTRACT_AND_EXPAND) || | ||
| !EVP_PKEY_CTX_set1_hkdf_salt( | ||
| ctx.get(), params.salt.data<unsigned char>(), params.salt.size()) || |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Does a non-zero-length key work with a 0-length salt?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Yes.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I know it's allowed, I am just wondering if OpenSSL implements it that way. The RFC's statement if not provided could be interpreted as "if the user does not call EVP_PKEY_CTX_set1_hkdf_salt".
Now I am confused as to whether an empty salt is the same as passing no salt in our current implementation.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Our implementation does not allow to omit passing salt, we require the argument, albeit we allow it to be zero-length.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Does a non-zero-length key work with a 0-length salt?
that's also covered by a passing wpt btw
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
My thought process was exactly the same. I know we're missing 0-length tests for every single operation we accept a SecretKeyObject in.
OpenSSL does support it, but this fix did not get extended to the particular API we use. I would happily use the new API but it's only available in 3 and we still have to support 1. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| params.key->GetSymmetricKeySize())) { | ||
| return false; | ||
| } | ||
| } else { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Could you add a brief comment to the beginning of the else branch to explain why it exists for future readers?
If we accept that this branch must exist (until we fully drop OpenSSL 1.1.1), then we should probably either
EVP_PKEY_HKDEF_MODE_EXTRACT_AND_EXPAND and pass the key to HMAC in this new branch (that should be equivalent as far as I can tell), orTODO comment saying to remove this branch once we have dropped OpenSSL 1.1.1.The first option would give us improved coverage because all HMAC operations would go through it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Could you add a brief comment to the beginning of the
elsebranch to explain why it exists for future readers?
Sure.
If we accept that this branch must exist (until we fully drop OpenSSL 1.1.1), then we should probably either
- remove the other branch that uses
EVP_PKEY_HKDEF_MODE_EXTRACT_AND_EXPANDand pass thekeytoHMACin this new branch (that should be equivalent as far as I can tell)
I think that can be done as a follow-up, I am not up for such challenge myself.
- add a
TODOcomment saying to remove this branch once we have dropped OpenSSL 1.1.1.
You mean to change the implementation to use EVP_KDF-HKDF when 1.1.1 is dropped?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| this.inProgress.delete(testFileName); | ||
| }); | ||
|
|
||
| await new Promise((resolve) => { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
If you want to reject when the worker emits an error event, you could also use
await events.once(worker, 'exit').
That being said, it looks like the caller never awaits the returned Promise (e.g., in test-webcrypto.js). What is the point in creating the Promise here if the caller does not await it?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
The point is to process the queue one by one. This has helped stabilize CI, especially the keygen tests that easily bogged the hosts down minutes at a time.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
If you want to
rejectwhen theworkeremits anerrorevent, you could also useawait events.once(worker, 'exit').
Rejecting would skip running the rest of the queue. So maybe this?
await Promise.allSettled([events.once(worker, 'exit')])
or
await events.once(worker, 'exit').catch(() => {})
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Now on the matter of eventually landing this. I propose to
commit-queue-rebase
WDYT? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I will pick this up again and break down to individual PRs after #43455 when every new WPT fixing PR will visibly show how many tests it fixes. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Split up into #44170, #44171, #44172, #44173, and #44201. Pulling updated WPT will be done after they land to avoid unnecessary conflicts. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.