Deno 1.13: Argument of type "jwk" is not assignable to parameter of type "raw"

[seanaye]

After upgrading to Deno v1.13.0 released today this library, specifically RSA can no longer be imported due to a typescript error.

in deno interpreter

> deno --version
1.13

> deno
> import { RSA }  from "https://deno.land/x/god_crypto/rsa.ts";
Uncaught TypeError: TS2345 [ERROR]: Argument of type '"jwk"' is not assignable to parameter of type '"raw"'.
    "jwk",
    ~~~~~
    at https://deno.land/x/god_crypto@v1.4.10/src/rsa/rsa_wc.ts:55:5
    at async <anonymous>:2:18

this works fine in Deno 1.12.x

[iugo]

Maybe it is related to https://github.com/denoland/deno/issues/11481. https://github.com/denoland/deno/pull/11662

[janusz-f]

I have the same error

[BayoKwendo]

Whats the solution to this

[Masoumeh-Hashemi]

this problem happened for me and I solved it in these steps:

1.because I had used "djwt" https://deno.land/x/djwt@v2.3 so I had to update it to the last release.

2.in the new release of djwt the format of the key has changed! and you should declare key using a function(according to djwt documentation).

`const key = await crypto.subtle.generateKey( { name: "HMAC", hash: "SHA-512" }, true, ["sign", "verify"], );

const jwt = await create({ alg: "HS512", typ: "JWT" }, { foo: "bar" }, key); `

now you are done! do the rest according to your new key format.

look which library have you used in your project(like denon,djwt,...), update them after upgrading deno

[lowlighter]

As this library directly uses deno's web crypto api, there's no solution yet because it's an upstream issue:

• https://github.com/denoland/deno/issues/11790
• https://github.com/denoland/deno/issues/11690
• https://github.com/denoland/deno/blob/23a9bc099d21ef7d45fe0f76e2fc53740ca98f6a/ext/crypto/00_crypto.js#L726

[danopia]

The unfortunate thing is that this library doesn't need WebCrypto at all. It was written to automatically switch to subtle crypto when available. Which didn't go well when subtle crypto was added with none of the expected algorithms, and similarly limited types as well.

Perhaps a good route to restore this library's function would be removing the unsupported subtle crypto codepaths & restoring them once Deno ships a release with the needed features. I see RSA-OAEP and AES-CBC referenced by this library. Neither can be imported into Deno yet. (Deno 1.13.0 will not want to typecheck these statements at all, so more @ts-ignore would then be needed for backwards compat 😢)

It seems /x/djwt already jumped over to using WebCrypto directly, so for JWT purposes maybe /x/jose is all we'll get on Deno 1.13.

[lowlighter]

It should be fixed for next deno release though. It has been implemented on canary since from what I seen.

I don't remember the release cycle but I think it's 2-4 weeks for minors so eventually it'll autofix with time

[danopia]

Ok so there's two different types of problem resulting from Deno implementing Subtle Crypto.

The first is the typecheck issue described in this issue. Supposedly the fix https://github.com/denoland/deno/pull/11716 will be in the next Deno canary. It doesn't seem to be in the latest canary, but the merge was recent. So apps depending on signing things with external RSA keys will just need to skip the current Deno release. (though --no-check seems safe because the relevant code isn't called as of Deno 1.13.2.)

The second issue is that god_crypto will use Subtle Crypto when it's "supported". A recent Deno merge added enough APIs (https://github.com/denoland/deno/pull/11654) to trigger this. So on the latest canary god_crypto will now call Subtle Crypto for encryption/decryption operations, which should fail until Deno's importKey learns RSA and/or AES. I don't see a public signal yet on when that would be.

In my previous comment I hadn't yet untangled the two different regressions. It's more clear now that the second issue would be a second ticket. It hasn't triggered yet as of Deno 1.13.2 and the codepath is only used for encrypt/decrypt operations, so it's not a problem for JWTs & maybe the API will be ready by the next Deno minor. 🤷

[lowlighter]

@danopia Thanks a lot for the additional details 👍

[laughedelic]

Does the new release of Deno v1.14 help with fixing this?

[BayoKwendo]

@laughedelic actually it got rid of that crypto bugs. i see deno is growing fast

[danopia]

Yes, Deno v1.14 includes enough types for god_crypto to pass typecheck again.

Also, as I warned above, Deno v1.14 now includes enough WebCrypto for god_crypto's encryption/decryption to fail. This is reproducible with the god_crypto test suite.

test results

``` failures: AES - Decryption AES-128-CBC (OpenSSL) DOMException: Unrecognized algorithm name AES - Decryption AES-256-CBC (OpenSSL) DOMException: Unrecognized algorithm name AES - CBC 128 bits key (Encryption) DOMException: Unrecognized algorithm name AES - CBC 128 bits key (Decryption) DOMException: Unrecognized algorithm name RSA - Decryption DOMException: Not implemented RSA - Encryption DOMException: Not implemented ```

So for JWT stuff aka signing/verifying if you want to stick with god_crypto just skip Deno v1.13 and use Deno v1.14