bean
bean14mo 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
ioB14mo ago
I can't reproduce this, your code runs fine for me. What does data contain? Could you log it and find out?
bean
beanOP14mo 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
ioB14mo 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
beanOP14mo ago
But its prefixed with SHA-256 TypeError so doesnt that indicate its an issue with the first parameter specifying the algo?
ioB
ioB14mo ago
Not sure, good question. From a google search it does seem that position 1 is the second argument.
bean
beanOP14mo ago
encode returns a Uint8Array so Im skeptical that a Uint8Array can be coerced to a string
ioB
ioB14mo 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
beanOP14mo 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
ioB14mo 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
beanOP14mo 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
ioB14mo 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
beanOP14mo 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
mmastrac14mo 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.