bean•13mo ago

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

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

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

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.

13 Replies

ioB•13mo ago

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

bean•13mo ago

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.

ioB•13mo ago

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?

bean•13mo ago

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

ioB•13mo ago

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

bean•13mo ago

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

ioB•13mo ago

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)

bean•13mo ago

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.

ioB•13mo ago

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?

bean•13mo ago

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?

ioB•13mo ago

I’m just running it in an unmodified deno build Which uses the same crates as you describe, though more up to date

bean•13mo ago

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.

mmastrac•13mo ago

Note that we've been porting ops to the new op2 system over the last month and there's some pretty strict lockstep requirements between deno_core and extensions (ie: what we release is supported) due to the pretty massive flux.