-
Notifications
You must be signed in to change notification settings - Fork 439
flesh out webcrypto #60
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
Conversation
Hi @rapropos, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! The agreement was validated by Microsoft and real humans are currently evaluating your PR. TTYL, MSBOT; |
unwrapKey(format: string, wrappedKey: ArrayBufferView, unwrappingKey: CryptoKey, unwrapAlgorithm: string | Algorithm, unwrappedKeyAlgorithm: string | Algorithm, extractable: boolean, keyUsages: string[]): any; | ||
verify(algorithm: string | Algorithm, key: CryptoKey, signature: ArrayBufferView, data: ArrayBufferView): any; | ||
wrapKey(format: string, key: CryptoKey, wrappingKey: CryptoKey, wrapAlgorithm: string | Algorithm): any; | ||
decrypt(algorithm: string | RsaOaepParams | AesCtrParams | AesCbcParams | AesCmacParams | AesGcmParams | AesCfbParams, key: CryptoKey, data: ArrayBuffer | ArrayBufferView): PromiseLike<ArrayBuffer>; |
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.
the algorithm parameter is of type AlgorithmIdentifier
, which can be defined as string|Algorithm
. not sure i see the point of enumerating all possible Algorithm types here.
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.
that also applies to all the other ones. i would suggest adding a new type alias:
type AlgorithmIdentifier = string | Algorithm;
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.
not sure i see the point of enumerating all possible Algorithm types here
I'm not sure I fully understood the point of this comment until looking at it again now that we have the ability to write type aliases. Assuming you are asking "why are you listing all those xxxParams types instead of just using AlgorithmIdentifier
?", the reason is that different algorithms have different allowed purposes, and I thought having them all enumerated would help users see at a glance which algorithms are usable for (e.g.) encrypting/decrypting and which are usable for signing/verifying.
Thank you for taking the time to comment. The documentation lists available types for adding as "property, method, interface, constructor, or indexer". None of those looked like they would be appropriate for defining the AlgorithmIdentifier and BufferSource aliases that you suggest, so I am unclear as to the proper procedure for defining them. |
@zhengbli, how can we define a type alias? |
} | ||
|
||
interface JsonWebKey { | ||
kty: string; |
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.
Why kty
is required while others are not? I didn't see any differences among these properties from the spec here
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.
@zhengbli: kty
is required because of the comment in RFC 7517 section 4.1 that says:
This member MUST be present in a JWK.
Sorry for the delay. With the latest updates in master, you can define a type alias like the follows: {
"kind": "typedef",
"name": "IDBValidKey",
"type": "number | string | Date | IDBArrayKey"
} |
Having the algorithm parameter to importKey be strictly an
|
CI seems to have failed due to some sort of network error. Is there a way I can try to rerun it? |
Seems like npm can't install tsd for now for some reason, tested on my local machine with the same result. I'll rerun the test later when it recovers. |
Squashed and rebased. |
digest(algorithm: AlgorithmIdentifier, data: BufferSource): PromiseLike<ArrayBuffer>; | ||
encrypt(algorithm: string | RsaOaepParams | AesCtrParams | AesCbcParams | AesCmacParams | AesGcmParams | AesCfbParams, key: CryptoKey, data: BufferSource): PromiseLike<ArrayBuffer>; | ||
exportKey(format: "jwk", key: CryptoKey): PromiseLike<JsonWebKey>; | ||
exportKey(format: "raw" | "pkcs8" | "spki", key: CryptoKey): PromiseLike<ArrayBuffer>; |
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.
this needs a string overload as well. otherwise somehing like:
var format = "jwk";
c.exportKey(format); /// Error
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.
Thank you. Added.
Thank you for this! I've been trying it locally and it fixes all my issues with WebCrypto breaking due to bad type definitions. However, I am now wrestling with |
@samuelhorwitz: Depending on your framework, the |
Yeah, I suppose so. I was just thrown through a loop because I guess there is no
This should probably be |
Incorporated @samuelhorwitz's catch on |
importKey(format: "raw" | "pkcs8" | "spki", keyData: BufferSource, algorithm: string | RsaHashedImportParams | EcKeyImportParams | HmacImportParams | DhImportKeyParams, extractable:boolean, keyUsages: string[]): PromiseLike<CryptoKey>; | ||
importKey(format: string, keyData: JsonWebKey | BufferSource, algorithm: string | RsaHashedImportParams | EcKeyImportParams | HmacImportParams | DhImportKeyParams, extractable:boolean, keyUsages: string[]): PromiseLike<CryptoKey>; | ||
sign(algorithm: string | RsaPssParams | EcdsaParams | AesCmacParams, key: CryptoKey, data: BufferSource): PromiseLike<ArrayBuffer>; | ||
unwrapKey(format: string, wrappedKey: BufferSource, unwrappingKey: CryptoKey, unwrapAlgorithm: AlgorithmIdentifier, unwrappedKeyAlgorithm: AlgorithmIdentifier, extractable: boolean, keyUsages: string[]): PromiseLike<ArrayBuffer>; |
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.
The spec says the unwrapKey
method returns PromiseLike<CryptoKey>
👍 @mhegazy further comments? |
1cddfa9
to
52fbb4c
Compare
Rebased again. It sure would be convenient if the parser could process a bunch of separate files instead of having two monolithic ones. Would cut down on the merge conflicts a ton. |
👍 |
@rapropos Thank you for your contribution! |
Previously, these methods returned PromiseLike, even though the spec has always required them to return real Promises and browsers have always done so. According to #60, this was done in order to work around #47; now that #47 has been fixed, this workaround is obsolete. This generally should not be a breaking change since it is making the SubtleCrypto type contract stricter and that API is generally implemented by the platform, not by users.
This should, among other things, sort of address TS issue #3984. Fully making the return type a
Promise
instead of aPromiseLike
is dependent on some sort of resolution of the ability to target the ES6 library separately. Reference document used to create these typings is the 2014.12 W3C WebCrypto API CR.Generally speaking, this should make code work that used to not compile (such as importing JSON web keys). The only more restrictive change, I believe, is making the
name
property ofAlgorithm
no longer optional. It is explicitly documented as required in the W3C document.