#Issues with Crypto Subtle Digest ext:deno_crypto/00_crypto.js

17 messages · Page 1 of 1 (latest)

austere shale
#

Currently we are using deno_core v0.200.0 deno_runtime v0.123.0 when attempting to invoke crypto.subtle.digest the following error is reported

SHA-256 TypeError: Error parsing args at position 1: serde_v8 error: invalid type; expected: object, got: string

example for reproduction

async function main() {
  const encoder = new TextEncoder();
  const data = encoder.encode('Hello, World!');
  const hashed = await crypto.subtle.digest('SHA-256', data);
  console.log(new Uint8Array(hashed));
}

According to the api docs either a string or enum should be supported as the first param.

inland belfry
#

I can't reproduce this, your code runs fine for me. What does data contain? Could you log it and find out?

austere shale
#

It contains Hello, World! UTF8 encoded but the error happens on attempting to deserialize SHA-256 to a enumeration type. the error looks to be around type conversion. We also tried turning SHA-256 to {name: 'SHA-256'} but it also errors.

inland belfry
#

I could be wrong, but me reading this error interprets it as data being the issue (TypeError: Error parsing args at position 1). Position 0 in my experience is the first input.

Any reason why your versions of deno_core and deno_runtime are out of date?

austere shale
#

But its prefixed with SHA-256 TypeError so doesnt that indicate its an issue with the first parameter specifying the algo?

inland belfry
#

Not sure, good question. From a google search it does seem that position 1 is the second argument.

austere shale
#

encode returns a Uint8Array so Im skeptical that a Uint8Array can be coerced to a string

inland belfry
#

Hold on, how do you even have TextEncoder with just deno_core and deno_runtime?

#

You'd need to have deno_web for that (or have implemented it yourself)

austere shale
#

We do use deno_web but its a modified version we have not modified be text encoding bindings nor bindings for the cryptp api's understandable if this is outside support scope.

inland belfry
#

Are you able to share a reproduction of this issue? I'd love to poke around. I'm assuming you all also have a vendored version of deno_crypto?

austere shale
#

no modified version of deno_crypto which is why this is a bit concerning. unfortunately i cannot give you a way to reproduce that can audit the behavior directly as its a remote execution environment where you wont have full log context.
we just use whats included in deno_runtime / deno_core and bind through our vendored deno_web bindings.

#

but knowning that you cannot reproduce using non vendored packages is interesting. May i ask how you are testing the above code example?

inland belfry
#

I’m just running it in an unmodified deno build

#

Which uses the same crates as you describe, though more up to date

austere shale
#

If anyone has more information on the error report that could also be helpful, from the looks of the logging structure it seems to be a type error with the first param but now not totally sure.

#

If anyone is able to run the source above through a env built from the exact package versions would help in our confidence in if its a bug in the op bindings or something on our end.