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
example for reproduction
According to the api docs either a string or enum should be supported as the first param.13 Replies
I can't reproduce this, your code runs fine for me. What does
data
contain? Could you log it and find out?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.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?But its prefixed with
SHA-256 TypeError
so doesnt that indicate its an issue with the first parameter specifying the algo?Not sure, good question. From a google search it does seem that
position 1
is the second argument.encode
returns a Uint8Array
so Im skeptical that a Uint8Array
can be coerced to a string
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)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.
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
?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?I’m just running it in an unmodified deno build
Which uses the same crates as you describe, though more up to date
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.
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.