wasm32-wasi doesn't build

[ruslan-belinskyy]

When building with:

rustup toolchain add 1.40.0
rustup target add wasm32-wasi
cargo wasi build

Getting:

error[E0432]: unresolved import `super::sysrand_chunk`
   --> /Users/210038/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/src/rand.rs:304:16
    |
304 |     use super::sysrand_chunk::chunk;
    |                ^^^^^^^^^^^^^ could not find `sysrand_chunk` in `super`

Cargo.toml

[package]
name = "sumo-collect"
version = "0.1.0"
authors = ["ruslan-belinskyy"]
edition = "2018"


[dependencies]
serde = "1.0.114"
serde_json = "1.0"
jsonwebtoken = "7.2.0"

[Geal]

I have the same issue (along with the wasm32-unknown-unknown target requiring web-sys). For the context, I'd need ring to work in wasm in a server side setting, so that I can use rustls there. I can provide help in testing solutions for this or even try to fix it in a few days

[Geal]

related PR: #900

[briansmith]

I'm happy to get WASI working. I think it is really simple to do now that wasm32-unknown-unknown is working.

What I'm missing is a recipe for testing it. I would love help getting the CI/CD running with a good, minimal-dependency, WASI runtime.

[ruslan-belinskyy]

We're using Fastly Lucet: https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime
But i didn't try to run it locally, because it didn't compile.

[briansmith]

I think I'm fine using Lucet or whatever. What I'm hoping for is a small shell script that downloads the necessary thing to run the tests under wasi and then runs the test under wasi, so that I can copy/paste that into the ring CI/CD scripts. Even better would be a PR that modifies the CI/CD scripts to get it working.

[briansmith]

I had to switch from Travis CI to GitHub Actions.

Please check out how the new GitHub Actions stuff in .github/workflows/ci.yml does it, particularly the test-wasm32 build matrix.

However, I think we can run the tests:

• In mk/install-build-tools.sh, when the target is WASI, download wasmtime (check out https://wasmtime.dev/install.sh). The only tricky part is that, whatever we download, we should check the sha256 sum, similar to what install-build-tools.ps1 does.

• In mk/cargo.sh:

    --target=wasm32-wasi)
      # The first two are only needed for when the "wasm_c" feature is enabled.
      export CC_wasm32_wasi=clang-10
      export AR_wasm32_wasi=llvm-ar-10
      export CARGO_TARGET_WASM32_WASI_RUNNER=wasmtime
      ;;

In particular, we should keep using cargo test to build. When starting out, before you get wasmtime or another runtime working in CI/CD, then add cargo_options: --no-run.

[briansmith]

PR #900 is a start at this. I asked for several changes to that PR.

[mpizenberg]

Hi, I'm also very much interested in this for an executable using ureq as a client http lib (and thus using ring via rustls)

[dzmitry-lahoda]

trying to compile libp2p

[dzmitry-lahoda]

from current rand

/// On wasm32-unknown-unknown (non-WASI), `fill()` is implemented using
/// `window.crypto.getRandomValues()`. It must be used in a context where the
/// global object is a `Window`; i.e. it must not be used in a Worker or a
/// non-browser context.

not sure why i cannot compile so. it seems has some support.
but because i am not in browser - it will not work anyway

[Jonas-Metzger]

I too would love if this gets resolved!

[briansmith]

I would very much appreciate somebody contributing a script that shows me how to run cargo test in a popular open-source WASI environment in GitHub Actions.

0. Which WASI runtime to use for testing in CI?
1. How do we install that WASI runtime in GitHub Actions?
2. How do we tell cargo test to use that WASI environment to run #[test] test_foo() { example::foo() } in an empty project example with lib.rs containing fn foo() { }.

Getting the test environment going in GitHub Actions is literally harder than the ~3 lines of code that are needed to get WASI working, but I can't write those 3 lines of code until somebody shares how to get the WASI test environment going.

[briansmith]

The old PR #900 was a good start at getting WASI working, but it sat for a long time, and I closed it due to inactivity and because it was bit-rotten.

For the upcoming release, PR #1413 makes the incremental step of getting rid of the assumption that wasm32-unknown-unknown is a browser environment. This will allow us to add support for making wasm32-unknown-unknown work in WASI environments too. See that PR for details.

My understanding is that cargo-wasi is currently considered the default way to test crates in a WASI environment. So, I guess the next step is to get cargo wasi test working in GitHub Actions.

[dotxlem]

@briansmith if you're still looking for someone to contribute here, I'd be happy to help! I have an immediate need to get ring working with WASM. For context, I'm migrating a fork of macaroon to ring for use in AssemblyLift.

[rjzak]

I was able to get a project using Ring to compile for wasm32-wasi, but I get this error:

Error: unknown import: env::ring_core_0_17_0_not_released_yet_p256_point_mul_base has not been defined.

@ruslan-belinskyy
I was able to get it to build by changing one of the cfg flags, code: https://github.com/rjzak/ring/blob/wasi_wip/src/rand.rs#L233 and a minor change to the Cargo.toml here https://github.com/rjzak/ring/blob/wasi_wip/Cargo.toml#L177

[kvinwang]

Related: #1499

[msuiche]

does that mean there is no wasi support?

[rjzak]

This works somewhat https://github.com/john-sharratt/ring/, but only things which are implemented only in Rust (Ring uses some C code) work in Wasi. It might be better to use Rust Crypto https://github.com/RustCrypto/ for Wasi projects, or Wasi-Crypto https://github.com/WebAssembly/wasi-crypto/

[briansmith]

Just to stop the radio silence from my end: I do intend to expand the support for WASI and I am interested in working together with others on this. The most immediate need is to make the changes discussed in #1499. Specifically, I outlined three steps that ideally would be split into at least 3 separate PRs, where the first step is to get what currently works building and testing in CI; this doesn't require any crypto knowledge whatsoever. Then we can expand the set of functionality that is available for WASI (and other WebAssembly) targets incrementally at a fast pace.

Just to reiterate, really no progress can be made until we have a CI solution, which again, we can model based on what getrandom already does.

[JanKaul]

I created a PR #1568 that should fix the first point (wasm32-wasi support). I had to make sure to use a CI action that installs the rust toolchain with rustup, otherwise wasmtime couldn't run the tests.

[RazaGR]

not solved still? facing same issue with cargo build --target wasm32-wasi --release

[rjzak]

@RazaGR Maybe use crates from RustCrypto instead?

[RazaGR]

@rjzak I am not using ring directly but it is listed as a dependency of few packages rustls sct webpki

[erikziyunchi]

@rjzak I am not using ring directly but it is listed as a dependency of few packages rustls sct webpki

+1, Did you find a way to get across this?

[rjzak]

We were running Steward in Enarx, and Enarx provides https for the Wasi application. But we also ripped out ring because of this very problem (lack of support, PRs not getting merged) and moved to Rust Crypto, since it's all pure Rust and works fine with wasm32-wasi.

Another option is to use Wasi-crypto, I have an example app.

[dynamite-bud]

We at @wasmerio compiled ring to wasi/wasix and want to make it upstream @briansmith .
The repo lives here.

@RazaGR @erikziyunchi @rjzak . You can check out our working fork. We're currently in the cleanup but it will work just fine. We also have rustls, sct, webpki everything working with wasix aka wasm32-wasmer-wasi and wasm32-wasi targets.

[xxchan]

I think the work #1568 is already there. No more forks are needed.

[dynamite-bud]

I think the work #1568 is already there. No more forks are needed.

@xxchan I tried building that fork:

WASI_SDK_PATH=/(...)/wasi/wasi-sdk cargo build --target wasm32-wasi                                                              1.71.0-nightly  2.90  4.88G 14:24:35  100%

   Compiling ring v0.17.0-not-released-yet (/(...)/ring)
error: no rules expected the token `unsafe`
  --> src/arithmetic/bigint/bn_mul_mont_fallback.rs:26:5
   |
26 |     unsafe fn bn_mul_mont(
   |     ^^^^^^ no rules expected this token in macro call
   |
  ::: src/prefixed.rs:1:1
   |
1  | macro_rules! prefixed_extern {
   | ---------------------------- when calling this macro
   |
note: while trying to match `fn`
  --> src/prefixed.rs:6:22
   |
6  |             $vis:vis fn $name:ident ( $( $arg_pat:ident : $arg_ty:ty ),* $(,)? )
   |                      ^^

warning: unused macro definition: `prefixed_export`
  --> src/prefixed.rs:44:14
   |
44 | macro_rules! prefixed_export {
   |              ^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_macros)]` on by default

warning: unused imports: `Limb`, `MODULUS_MAX_LIMBS`, `N0`, `limbs_from_mont_in_place`, `limbs_mul`
  --> src/arithmetic/bigint/bn_mul_mont_fallback.rs:22:13
   |
22 | use super::{limbs_from_mont_in_place, limbs_mul, Limb, MODULUS_MAX_LIMBS, N0};
   |             ^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^  ^^^^  ^^^^^^^^^^^^^^^^^  ^^
   |
   = note: `#[warn(unused_imports)]` on by default

warning: unused import: `crate::c`
  --> src/arithmetic/bigint/bn_mul_mont_fallback.rs:23:5
   |
23 | use crate::c;
   |     ^^^^^^^^

warning: `ring` (lib) generated 3 warnings
error: could not compile `ring` (lib) due to previous error; 3 warnings emitted

[xxchan]

Well, in this case maybe you should leave the review in that PR first :)

I'm not sure which one works, but just want to say it's not friendly and efficient to ignore other people's existing work.

[dynamite-bud]

Well, in this case maybe you should leave the review in that PR first :)

I'm not sure which one works, but just want to say it's not friendly and efficient to ignore other people's existing work.

Apologies for that @xxchan I tried both #1568 and #1499 first.
Both of them didn't work out. Then created the fork.

[rjzak]

There have been a few PRs for Wasi support that seem to go unmerged. It would be nice to get input from @briansmith on how to get Wasi support actually merged and supported.

[JanKaul]

I think the work #1568 is already there. No more forks are needed.

@xxchan I tried building that fork:

WASI_SDK_PATH=/(...)/wasi/wasi-sdk cargo build --target wasm32-wasi                                                              1.71.0-nightly  2.90  4.88G 14:24:35  100%

   Compiling ring v0.17.0-not-released-yet (/(...)/ring)
error: no rules expected the token `unsafe`
  --> src/arithmetic/bigint/bn_mul_mont_fallback.rs:26:5
   |
26 |     unsafe fn bn_mul_mont(
   |     ^^^^^^ no rules expected this token in macro call
   |
  ::: src/prefixed.rs:1:1
   |
1  | macro_rules! prefixed_extern {
   | ---------------------------- when calling this macro
   |
note: while trying to match `fn`
  --> src/prefixed.rs:6:22
   |
6  |             $vis:vis fn $name:ident ( $( $arg_pat:ident : $arg_ty:ty ),* $(,)? )
   |                      ^^

warning: unused macro definition: `prefixed_export`
  --> src/prefixed.rs:44:14
   |
44 | macro_rules! prefixed_export {
   |              ^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_macros)]` on by default

warning: unused imports: `Limb`, `MODULUS_MAX_LIMBS`, `N0`, `limbs_from_mont_in_place`, `limbs_mul`
  --> src/arithmetic/bigint/bn_mul_mont_fallback.rs:22:13
   |
22 | use super::{limbs_from_mont_in_place, limbs_mul, Limb, MODULUS_MAX_LIMBS, N0};
   |             ^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^  ^^^^  ^^^^^^^^^^^^^^^^^  ^^
   |
   = note: `#[warn(unused_imports)]` on by default

warning: unused import: `crate::c`
  --> src/arithmetic/bigint/bn_mul_mont_fallback.rs:23:5
   |
23 | use crate::c;
   |     ^^^^^^^^

warning: `ring` (lib) generated 3 warnings
error: could not compile `ring` (lib) due to previous error; 3 warnings emitted

As described here, you have to set the environment variables accordingly.

export WASI_SDK_PATH=`pwd`/wasi-sdk
CC="${WASI_SDK_PATH}/bin/clang --sysroot=${WASI_SDK_PATH}/share/wasi-sysroot"

[briansmith]

Fixed by #1745 and #1746.