signer: enable schnorrkel/getrandom feature

[ordian]

Without this I get a https://github.com/burdges/getrandom_or_panic/blob/8dc0f4d43c9aebfefcd0b8a226b40ef33e56f9c0/src/lib.rs#L21 from getrandom_or_panic crate in both wasm and regular no-std builds that try to sign something.

[jsdw]

Interesting! We test basic signing in our CI here:

https://github.com/paritytech/subxt/blob/master/signer/wasm-tests/tests/wasm.rs

I wonder what's different between those tests and your setup; would you have an example you could share?

This comment is also interesting: https://github.com/w3f/schnorrkel/blob/master/Cargo.toml#L65

[ordian]

https://github.com/ordian/subxt-1871-repro

[jsdw]

Thankyou!

Ok so running natively, enabling the "std" feature seems to make everything work. I guess sr25519 uses randomness but thought we avoided this in no-std mode so I'll have to look at why it doesn't work without std.

If you were to compile and run this in WASM, we have a "web" feature which should make things work (it enables getrandom's JS feature to get the randomness from JS land). Does this work for you in WASM builds (you may need the "std" feature too but not sure)?

[ordian]

Does this work for you in WASM builds (you may need the "std" feature too but not sure)?

No, enabling getrandom/js feature doesn't enable getrandom_or_panic/getrandom feature.

I'm not sure how the wasm tests work here. Is it possible that std feature leaks?

I haven't tried enabling std feature in wasm and it will likely work, but seems like an overkill.

[jsdw]

I added the getrandom feature you suggested (albeit in a different place) and adding some nostd tests which reproduced your issue and work with that feature in #1872. If the CI passes for that then I think that's the way to go! I'd be very grateful if you could try that branch and see if it all works for you :)

[ordian]

Closing in favor of #1872