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.