flesh out webcrypto #60

rapropos · 2016-01-30T22:30:15Z

This should, among other things, sort of address TS issue #3984. Fully making the return type a Promise instead of a PromiseLike 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 of Algorithm no longer optional. It is explicitly documented as required in the W3C document.

msftclas · 2016-01-30T22:30:20Z

Hi @rapropos, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

mhegazy · 2016-02-01T20:04:30Z

baselines/dom.generated.d.ts

-    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>;


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.

that also applies to all the other ones. i would suggest adding a new type alias:

type AlgorithmIdentifier = string | Algorithm;

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.

rapropos · 2016-02-01T20:40:16Z

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.

mhegazy · 2016-02-01T20:41:38Z

@zhengbli, how can we define a type alias?

zhengbli · 2016-03-21T15:55:38Z

baselines/dom.generated.d.ts

+}
+
+interface JsonWebKey {
+    kty: string;


Why kty is required while others are not? I didn't see any differences among these properties from the spec here

@zhengbli: kty is required because of the comment in RFC 7517 section 4.1 that says:

This member MUST be present in a JWK.

zhengbli · 2016-03-21T15:58:03Z

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"
    }

rapropos · 2016-03-23T21:11:18Z

Having the algorithm parameter to importKey be strictly an AlgorithmIdentifier instead of enumerating the possible types causes problems in my client code:

this.subtle.importKey("jwk", pubjwk,
                                {name: "RSASSA-PKCS1-v1_5", hash: {name: "SHA-256"}},
                                true, ["verify"])
                                .then((pubkey:CryptoKey) => {
                                    this.accessKeys.publicKey = pubkey;
                                })

Argument of type '{ name: string; hash: { name: string; }; }' is not assignable to parameter of type 'string | Algorithm'.
  Object literal may only specify known properties, and 'hash' does not exist in type 'string | Algorithm'.

rapropos · 2016-03-23T21:28:42Z

CI seems to have failed due to some sort of network error. Is there a way I can try to rerun it?

zhengbli · 2016-03-23T21:37:31Z

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.

rapropos · 2016-03-24T21:48:37Z

Squashed and rebased.

mhegazy · 2016-03-24T22:35:20Z

baselines/dom.generated.d.ts

+    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>;


this needs a string overload as well. otherwise somehing like:

var format = "jwk"; c.exportKey(format); /// Error

Thank you. Added.

samuelhorwitz · 2016-04-01T04:23:06Z

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 Promise versus PromiseLike sadly. Anyway, hopefully this gets merged into TS soon.

rapropos · 2016-04-01T21:16:55Z

@samuelhorwitz: Depending on your framework, the PromiseLike/Promise business may turn out to be a blessing in disguise. I ran into some subtle problems with Angular2, whereby it inserts some zone magic into its Promises that isn't sprinkled on the things coming back from WebCrypto. Having the return value be a PromiseLike reminds me that I need to wrap everything coming back from WebCrypto in Promise.resolve() in order for the change detection to fire correctly. In any event, whatever your Promise library, that resolve wrap should be sufficient to convert a PromiseLike to a Promise.

samuelhorwitz · 2016-04-03T18:05:29Z

Yeah, I suppose so. I was just thrown through a loop because I guess there is no catch on promise likes and I just walked away from the code for a bit, frustrated about how just trying to upgrade Typescript led to so much issues. But anyway I found something else that might be wrong with the PR but I don't know enough about the specs to say:

interface EcKeyImportParams {
    typedCurve: string;
}

This should probably be namedCurve. That's what Chrome expects, at least. Not sure if this is some discrepancy between spec and implementation (haven't looked at the spec).

rapropos · 2016-04-03T20:30:03Z

Incorporated @samuelhorwitz's catch on EcKeyImportParams and resquashed.

zhengbli · 2016-04-18T18:47:28Z

baselines/dom.generated.d.ts

+    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>;


The spec says the unwrapKey method returns PromiseLike<CryptoKey>

zhengbli · 2016-04-18T20:05:11Z

👍 @mhegazy further comments?

rapropos · 2016-05-12T20:59:41Z

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.

mhegazy · 2016-05-17T00:17:43Z

👍

zhengbli · 2016-05-17T00:18:50Z

@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.

msftclas added the cla-already-signed label Jan 30, 2016

mhegazy reviewed Feb 1, 2016
View reviewed changes

This was referenced Feb 4, 2016

TypeScript support square/js-jose#26

Closed

TypeScript typings square/js-jose#28

Merged

zhengbli reviewed Mar 21, 2016
View reviewed changes

rapropos force-pushed the webcrypto branch from 3dc7e36 to c4e811b Compare March 21, 2016 23:15

rapropos force-pushed the webcrypto branch from 72c7df4 to 0dcd452 Compare March 24, 2016 21:11

mhegazy reviewed Mar 24, 2016
View reviewed changes

samuelhorwitz mentioned this pull request Apr 1, 2016

SubtleCrypto interface type definitions not valid microsoft/TypeScript#7761

Closed

rapropos force-pushed the webcrypto branch from 17c9135 to 95f481d Compare April 3, 2016 20:28

zhengbli reviewed Apr 18, 2016
View reviewed changes

rapropos force-pushed the webcrypto branch 2 times, most recently from 1cddfa9 to 52fbb4c Compare April 19, 2016 22:53

flesh out webcrypto

94ac2a1

rapropos force-pushed the webcrypto branch from 52fbb4c to 94ac2a1 Compare May 12, 2016 20:43

zhengbli merged commit e577388 into microsoft:master May 17, 2016

zhengbli mentioned this pull request May 17, 2016

Bug: Incorrect return type of SubtleCrypto.digest microsoft/TypeScript#3984

Closed

rapropos referenced this pull request in square/js-jose May 17, 2016

typings lacks JsonWebKey, JWK RSA interfaces fix

398a8b5

taymonbeal mentioned this pull request Mar 25, 2020

Change SubtleCrypto method return types to Promise #843

Merged

taymonbeal mentioned this pull request Apr 2, 2020

SubtleCrypto methods return PromiseLike instead of Promise microsoft/TypeScript#37756

Closed

flesh out webcrypto #60

flesh out webcrypto #60

Uh oh!

Conversation

rapropos commented Jan 30, 2016

Uh oh!

msftclas commented Jan 30, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rapropos commented Feb 1, 2016

Uh oh!

mhegazy commented Feb 1, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zhengbli commented Mar 21, 2016

Uh oh!

rapropos commented Mar 23, 2016

Uh oh!

rapropos commented Mar 23, 2016

Uh oh!

zhengbli commented Mar 23, 2016

Uh oh!

rapropos commented Mar 24, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

samuelhorwitz commented Apr 1, 2016

Uh oh!

rapropos commented Apr 1, 2016

Uh oh!

samuelhorwitz commented Apr 3, 2016

Uh oh!

rapropos commented Apr 3, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zhengbli commented Apr 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rapropos commented May 12, 2016

Uh oh!

mhegazy commented May 17, 2016

Uh oh!

zhengbli commented May 17, 2016

Uh oh!

Uh oh!

zhengbli commented Apr 18, 2016 •

edited

Loading