run miri for a big-endian target

[Skgland]

Currently I expect CI to fail, after #3311 this should pass.

Add a new crypto feature so that crypto dependencies can be disabled so that this works without having to setup native libraries and toolchain for the big-endian target.

> cargo +nightly miri test --lib --target s390x-unknown-linux-gnu --no-default-features --features=repl,hostname

<!-- SNIP --> 

failures:

---- arena::tests::heap_put_literal_tests stdout ----

thread 'arena::tests::heap_put_literal_tests' (1003) panicked at src/arena.rs:734:17:
internal error: entered unreachable code
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
note: in Miri, you may have to set `MIRIFLAGS=-Zmiri-env-forward=RUST_BACKTRACE` for the environment variable to have an effect


failures:
    arena::tests::heap_put_literal_tests

test result: FAILED. 29 passed; 1 failed; 42 ignored; 0 measured; 0 filtered out; finished in 81.65s

error: test failed, to rerun pass `--lib`

> git merge eac7ff680ce7a9f95bc88daaa7c0339f2bf494b8
> cargo +nightly miri test --lib --target s390x-unknown-linux-gnu --no-default-features --features=repl,hostname

<!-- SNIP --> 

test result: ok. 30 passed; 0 failed; 42 ignored; 0 measured; 0 filtered out; finished in 81.74s

[Skgland]

Marking as draft while I fiddle with CI

[triska]

Why is it necessary to disable so much functionality for this? Would it not be much preferable if this functionality were tested on big-endian targets too, especially due to its criticality?

[Skgland]

I got cross-compilation with the crypto-full and ffi features working.

Not working is

• features http and tls, fail at cross-compiling openssl
• running tests outside of miri
  • tried using qemu-system-s390x with qemu-user-binfmt but couldn't get it working

[Skgland]

I give up on getting openssl cross-compilation and running test via qemu working.
Maybe someone else can figure that out.

As such I consider this ready.

[Skgland]

As such I consider this ready.

Well, with the caveat that it requires #3311 to actually pass CI.

[triska]

None of the hash functions or signing and key exchange functionality requires OpenSSL, is it really necessary to make so much optional? I would hope this compiles on many more platforms, at least that was a key motivation for me to implement much of the cryptographic functionality so that it does not require OpenSSL.

[Skgland]

None of the hash functions or signing and key exchange functionality requires OpenSSL, is it really necessary to make so much optional? I would hope this compiles on many more platforms, at least that was a key motivation for me to implement much of the cryptographic functionality so that it does not require OpenSSL.

Initially I hadn't cross-compilation working yet so I had to gate the crypto functions depending on ring.
I didn't have a better name for the feature gate than just crypto and then it felt odd to have crypto function that would work without that feature, so all got gated.

Given that I got cross-compilation of ring working the first commit adding the crypto feature isn't strictly necessary anymore so I could drop that commit.

Having a way to build without non-rust dependencies might still be nice.

[triska]

Having a way to build without non-rust dependencies might still be nice.

Yes indeed, and much of the cryptographic functionality is entirely Rust-based. For instance, the Ed25519 and Curve25519 functionality for signing and key exchange, and crypto_curve_scalar_mult, use the excellent crrl crate which to the best of my knowledge is entirely Rust-based. It would be great to have this functionality on all targets, I see no reason to make its compilation optional if it compiles successfully.

[Skgland]

Marking this as draft until I get around to dropping commit 9648607 from this PR.

I intend to open a separate PR for making ring optional.
Currently considering ring-crypto or crypto-ring for the feature name as I don't think crypto as a feature name fits if it doesn't disable/enable all crypto functions.
@triska do you maybe have an idea/suggestions for what to name the feature?

[triska]

an idea/suggestions for what to name the feature?

It sounds like what could be useful also more generally is to compile Scryer exclusively with those parts that are implemented natively in Rust, so maybe rust-only, would that make sense and be useful for supporting as many platforms as possible?

[Skgland]

merged #3311 into this, to get the fix this is adding testing for, so that CI is green