Add a global-context-less-secure feature which skips randomization

[TheBlueMatt]

This is useful for us downstream as we wish to target WASM with a
global context, and using rand in such a build doesn't seem like a
safe idea.

[real-or-random]

I guess that's okay but can you explain why using rand isn't a safe idea?

[TheBlueMatt]

Well, mostly I’m not sure how you’d need to map JavaScript functions into the WASM env in order to get rand to work - it needs external access to work at all. Ideally it’s also possible to use a global context without std, though we need sync::Once for that (under the hood it’s all atomics and thread::park, so we could drop the park and do it ourselves easily).

…

On Feb 15, 2021, at 07:05, Tim Ruffing ***@***.***> wrote:  I guess that's okay but can you explain why using rand isn't a safe idea? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[elichai]

@TheBlueMatt which wasm target have std and doesn't have rand support?

[elichai]

Also, see bitcoin-core/secp256k1#893 for fully non std global context

[TheBlueMatt]

Currently we're building rust-lightning targeting wasm32-wasi, but linking it with C code and not exposing any of the wasi runtime to the wasm binary.

[TheBlueMatt]

Rebased to pick up new upstream CI with no other changes.

[TheBlueMatt]

Rebased on latest upstream to fix our Cargo patches. Any update on getting this landed?

[apoelstra]

ack ce930ab

I'm not totally thrilled about the "less secure" name but I'm not sure what would be better.

[Kixunil]

FYI @TheBlueMatt getrandom now has js feature which you can turn on to get WASM with JS working correctly.

[apoelstra]

Lol, wow, when I saw your "why is this a feature?" issue I couldn't remember the reason, but I am a little surprised it was "WASM compatibility".

We can drop the features now; we haven't had any issues with randomness in particular for a few years in wasm. Other than remembering to turn on that feature. (But then I think the correct solution is to detect at compile-time if we are targeting wasm and the feature isn't turned on.)

[Kixunil]

But then I think the correct solution is to detect at compile-time if we are targeting wasm and the feature isn't turned on.

Their code already has compile_error but while targeting wasm is possible to detect, it's not possible to detect whether it supports JavaScript. From their doc:

This crate fully supports the wasm32-wasi and wasm32-unknown-emscripten targets. However, the wasm32-unknown-unknown target (i.e. the target used by wasm-pack) is not automatically supported since, from the target name alone, we cannot deduce which JavaScript interface is in use (or if JavaScript is available at all).

Instead, if the js Cargo feature is enabled, this crate will assume that you are building for an environment containing JavaScript, and will call the appropriate methods. Both web browser (main window and Web Workers) and Node.js environments are supported, invoking the methods described above using the wasm-bindgen toolchain.

[apoelstra]

Oh, wonderful. I'm glad they have a compile error now. At the time of this issue in was a runtime panic in a very obscure location, which as I mentioned elsewhere, would present as a blank webpage.