god_crypto icon indicating copy to clipboard operation
god_crypto copied to clipboard

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

Open seanaye opened this issue 3 years ago • 12 comments

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/[email protected]/src/rsa/rsa_wc.ts:55:5
    at async <anonymous>:2:18

this works fine in Deno 1.12.x

seanaye avatar Aug 11 '21 01:08 seanaye

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

iugo avatar Aug 12 '21 10:08 iugo

I have the same error

janusz-f avatar Aug 20 '21 15:08 janusz-f

Whats the solution to this

BayoKwendo avatar Aug 26 '21 01:08 BayoKwendo

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

1.because I had used "djwt" https://deno.land/x/[email protected] 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 **

Masoumeh-Hashemi avatar Aug 26 '21 14:08 Masoumeh-Hashemi

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

lowlighter avatar Aug 26 '21 17:08 lowlighter

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.

danopia avatar Aug 28 '21 09:08 danopia

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

lowlighter avatar Aug 28 '21 10:08 lowlighter

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

danopia avatar Aug 28 '21 13:08 danopia

@danopia Thanks a lot for the additional details 👍

lowlighter avatar Aug 28 '21 14:08 lowlighter

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

laughedelic avatar Sep 20 '21 15:09 laughedelic

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

BayoKwendo avatar Sep 22 '21 00:09 BayoKwendo

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

danopia avatar Sep 23 '21 18:09 danopia