Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wasm32 target support #141

Closed
briansmith opened this issue Nov 11, 2020 · 10 comments
Closed

Add wasm32 target support #141

briansmith opened this issue Nov 11, 2020 · 10 comments

Comments

@briansmith
Copy link
Owner

No description provided.

@briansmith
Copy link
Owner Author

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

@briansmith
Copy link
Owner Author

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

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

@brenzi
Copy link

brenzi commented Feb 16, 2021

@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
Copy link

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
Copy link

DanGould commented Feb 9, 2024

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

@briansmith
Copy link
Owner Author

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
Copy link

DanGould commented Feb 9, 2024

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
Copy link
Owner Author

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
Copy link

DanGould commented Feb 9, 2024

That works for me. Thanks for the tip

@briansmith
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants