You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Safe/reliable crypto.KeyObject and webcrypto.CryptoKey detection in userland #38611
Currently there are no public methods for checking for KeyObject and CryptoKey objects. Having reliable checks for these would be very nice to have for userland code that wants to support these types of objects in their code.
It seems there are already internal methods for achieving this, but I'm not sure why they are not currently exposed to userland. I was thinking maybe something like how Buffer handles this: KeyObject.isKeyObject() and CryptoKey.isCryptoKey(). The former is currently pretty easy to do in userland since it's just doing an instanceof check, but the latter checks "private" symbols, which is not as easy/ideal for userland (although I guess at least currently instanceof CryptoKey would work?). Either way, having these encapsulated in helper methods would help insulate changes to the checking logic, should it ever change.
Re KeyObject: When I designed the new APIs, I intentionally did not expose that class directly. The only reason we did so eventually is such that users can rely on instanceof KeyObject.
I still think it would be a good idea to expose static .is*() methods in case the method of detection should change in the future (e.g. instanceof to symbol check) as with Buffer.isBuffer() (where the detection method did change over time).
CryptoKey.isCryptoKey() is problematic because it extends the standard API in a non-standard way. As I suggest in @panva's PR, we could add both checks to KeyObject:
Activity
tniessen commentedon May 9, 2021
Re
KeyObject: When I designed the new APIs, I intentionally did not expose that class directly. The only reason we did so eventually is such that users can rely oninstanceof KeyObject.tniessen commentedon May 9, 2021
See #26200 and #26438.
mscdex commentedon May 9, 2021
I still think it would be a good idea to expose static
.is*()methods in case the method of detection should change in the future (e.g.instanceofto symbol check) as withBuffer.isBuffer()(where the detection method did change over time).panva commentedon May 10, 2021
Both
instanceof crypto.KeyObjectandinstanceof crypto.webcrypto.CryptoKeywork so long as the code doesn't run e.g. in avmcontext.I think exposing a symbol check function would be better.
jasnell commentedon May 10, 2021
CryptoKey.isCryptoKey()is problematic because it extends the standard API in a non-standard way. As I suggest in @panva's PR, we could add both checks toKeyObject:Alternatively, we could add both to
util/typesIf the Node.js binary is built without crypto support, these would still exist but would always return
false.mscdex commentedon May 10, 2021
I don't have a strong preference where the functions live, just that they're available in some sensible place.
util: add util.types.isKeyObject and util.types.isCryptoKey
util: add util.types.isKeyObject and util.types.isCryptoKey