Add wasm32 target support

[briansmith]

[briansmith]

All the tests need to be adapted to use wasm-bindgen-test.

[briansmith]

I think this is dependent on a few changes to ring and probably no changes to webpki:

• [ ] Remove ring's assumption that wasm32-unknown-unknown is targeting WebAssembly and more generally allow it to work for applications that don't need ring::rand; see https://github.com/briansmith/ring/issues/1172.
• [ ] ring currently doesn't expose all the signature verification algorithms for WebAssembly targets; see https://github.com/briansmith/ring/issues/918#issuecomment-640778292 to a brief explanation. There are a few PRs in progress (some posted on GitHub) to move towards solving this.
• [ ] Add -wasi support to ring: https://github.com/briansmith/ring/issues/1043

Once the ring issues are addressed, I expect this issue will be reduced to:

• [ ] enable the right features of ring in webpki's Cargo.toml, based on the resolution of https://github.com/briansmith/ring/issues/1172
• [ ] Add testing of the wasm32 targets to webpki's CI.

[brenzi]

@briansmith: This is an important feature for us. We would be willing to fund a bounty (i.e. gitcoin) to have this resolved. But we'd need an estimate of efforts

[earthengine]

Given a bit of research and digging into the issue, I believe it would be better to isolate dependency of ring and allow it to build without - in that case we need the user to implement the algorithm in other ways. For example, for wasm32-unknown-unknown aka inside a browser, we can still support it through the browser Crypto API.

[DanGould]

At this point all that's left is testing wasm32-unknown-unknown targets to webpki's CI, correct?

[briansmith]

At this point all that's left is testing wasm32-unknown-unknown targets to webpki's CI, correct?

I think the wasm32-wasi testing in webpki's CI, in combination with the more thorough testing in ring's CI that includes wasm32-unknown-unknown in a browser, is enough. After all, there is no target-specific code in webpki. So I think we can close this.

WDYT?

[DanGould]

I was just writing CI and realized similar, there is no (wasm-bindgen-test) target-specific testing to do.

However a feature like wasm32_unknown_unknown_js = ["ring/wasm32_unknown_unknown_js"] needs to be exposed in order to build in wasm32-unknown-unknown.

Would you consider accepting a PR creating that specific feature + the modification to CI to exclude it from the matrix which now calls --all-features? Merely testing that wasm32-unknown-unknown builds would also be appropriate.

[briansmith]

However a feature like wasm32_unknown_unknown_js = ["ring/wasm32_unknown_unknown_js"] needs to be exposed in order to build in wasm32-unknown-unknown.

We don't need this feature because you can just do this in your Cargo.toml:

[dependencies]
ring = { version = "0.17", features = ["ring/wasm32_unknown_unknown_js"]  }

Even if your application doesn't depend directly on ring, this is how you enable its features.

Otherwise, if we add the feature you are proposing, then we create more maintenance work for ourselves within webpki, as we now have more configurations to support.

[DanGould]

That works for me. Thanks for the tip

[briansmith]

Thanks for the feedback. I'm going to close this now, as complete.