schnorrkel: no_std is broken, doesn't play with sgx

Schnorrkel actually works if patching ed25519-dalek to my fork:

[patch.crates-io]
ed25519-dalek = { git = "https://github.com/scs/ed25519-dalek.git", branch = "no_std_sgx"}

Attempting to remove sha2 just because you think it breaks no_std build looks like an overkill to me. If problem indeed originates in RustCrypto crates, please, report it and I will try to fix it ASAP.

Anyway, I’ve just re-run no_std CI test for RustCrypto/hashes and it has passed without any issues. I highly doubt problem is in opaque_debug, as you can see here, code is dead simple and does not use std anywhere.

Also, please read the compilation error message more carefully:

error: Could not compile rand_core.

I guess, std feature gets enabled for rand_core, so probably one of the dependencies has forgot to use default-features = false and correctly cascade std feature.

Thanks anyways @dhardy 😃

It’s opaque-debug that fails due to some no_std between it and that platform? It’s seemingly used by sha2 and sha3. Can you build sha2 all by itself? If not ask @newpavlov

I sadly cannot purge sha2 from this crate, due to kusama using the ExpansionMode::Ed25519 option. I could however feature gate sha2 so that you can avoid using it if you never transfer secrets with kusama’s subkey, etc. And we’ll might dump ExpansionMode::Ed25519 in polkadot. Also, you could fork schnorrkel using some sha2 crate without the complex dependencies.

Just fyi, we cannot purge the digest crate because curve25519-dalek depends upon it, but we do not depend upon digest for anything important, so again digest could be avoided in some fork of both curve25519-dalek and schnorrkel. We’d then have dependencies down to exclusive dalek ecosystem and lower level rand crates.

@burdges thanks for the update. I won’t be able to test it until next week.

If you’re okay with using nightly compilers only, I have a merlin branch that might work for you: https://github.com/dalek-cryptography/merlin/pull/42