search

tc39 / proposal-csprng

Cryptographically Secure Random Number Generation for ECMAScript
BSD 3-Clause "New" or "Revised" License
70 stars 9 forks source link

Add spec text to be compatible with WebCrypto #2

Open rbuckton opened 4 years ago

rbuckton commented 4 years ago

This Draft PR is intended to explore the possibility of devising a crypto global that would be compatible with the Web Cryptography API, such that web hosts could extend the API to encompass the full Web Cryptography API without issues with compatibility.

bmeck commented 4 years ago

be aware that the default node repl exposes builtin modules as globals and crypto is the name of one of them.

$ echo 'typeof globalThis.crypto' | node -i
Welcome to Node.js v12.13.1.
Type ".help" for more information.
> typeof globalThis.crypto
'object'
rbuckton commented 4 years ago

I am aware, and mentioned that during the meeting as well.

ljharb commented 4 years ago

I don't think there's much of a concern with breaking this feature of node's repl, tho, is there?

bmeck commented 4 years ago

I have no opinion on breakage, just want to keep it recorded as being thought about.

rbuckton commented 4 years ago

@bmeck I made your comment into an issue so that we can ensure we track this and follow up with someone from Node about concerns and possible remediations.

bakkot commented 4 years ago

There's a slight difference here in that getRandomValues as currently specified in WebCrypto must be invoked with a receiver which is a crypto object: (0, crypto.getRandomValues)(new Uint8Array()) fails.

Note that the receiver just needs to be a crypto object:

let i = document.createElement('iframe');
document.body.append(i);
i.contentWindow.crypto.getRandomValues.call(crypto, new Uint8Array());

works.

The fact that crypto works this way is pretty unfortunate and, as I understand it, is just an accident of history: I'm pretty sure it's because crypto was specified before namespaces were introduced to WebIDL, which was done specifically to make (0, console.log)() work (done here). But it is what it is.

rbuckton commented 4 years ago

I don't believe this to be a web compatibility issue, however. Not throwing an error shouldn't make any existing code break today, though it would be worthwhile to discuss this more with someone directly involved with the WebCrypto spec about maintaining compatibility.

rbuckton commented 4 years ago

@bakkot I've also made your comment above a separate issue so that we can track the discussion.