wasm support?

[cBournhonesque]

Hi, I apologize if it's a dumb question.

I was trying to build my code for wasm32-unknown-unknown and I was getting a failure because of the ring library. (not sure why, because apparently ring is compatible with wasm)

Does this library build for wasm? Is there a plan to support this in the future?

[BiagioFesta]

I am wondering if this incompatibility came from the latest version of wtransport (i.e., 0.1.9), as I had to directly bring ring for cryptographic certificate fingerprint computation.

Does version 0.1.8 suffers of the same issue?

---

Moreover, you might find interesting projects that use wtransport with wasm integration. For example:

• https://github.com/MOZGIII/xwt an abstraction layer that generalize a common API for both native and browser (powered by wtransport)
• I recently saw on reddit a game: https://www.reddit.com/r/rust/comments/17pre31/a_multiplayer_snake_game_with_bevy_and/, I game powered by bevy (game engine) and wtransport for client-server communication

Maybe those links can give you some hints

[cBournhonesque]

It still fails with 0.1.8.

Here's my

cargo tree -i ring@0.17.6

ring v0.17.6
├── rustls v0.21.9
│   ├── quinn v0.10.2
│   │   └── wtransport v0.1.8
│   │       └── lightyear v0.2.0 
│   ├── quinn-proto v0.10.6
│   │   └── quinn v0.10.2 (*)
│   └── wtransport v0.1.8 (*)
├── rustls-webpki v0.101.7
│   └── rustls v0.21.9 (*)
└── sct v0.7.1
    └── rustls v0.21.9 (*)

So ring also comes from quinn itself. What I don't get is that ring should be able to compile for wasm32-unknown-unkown.

Thanks for the links!

[cBournhonesque]

Hi just a question; The serverCertificateHash option here

would be a sha-256 hash of the certificates generated in your crate?

So basically it would be a base64-decoded version of those "fingerprints" here ?

[BiagioFesta]

Yes, W3C serverCertificateHashes is the hash (sha256) of the certificates.

Previously wtransport::Certificate had fingerprint method which was returning a base64 of the public key of the certificate (not the entire certificate). Therefore, that was not related to serverCertificateHashes.

That "fingerprint" was used to make Google Chrome accepts the self-signed certificate with the command line option --ignore-certificate-errors-spki-list={cert_fingerprint}.

However I did not like that, because it required Google Chrome to be launched with that argument line option (and it is not very user-friendly).

---

Today, starting from that commit, wtransport::Certificate does not return that fingerprint anymore. It instead returns the entire certificate bytes so user of that struct can compute whatever they need for that certificate.

In particular, I leverage that in the example/full.rs to indeed compute the SHA256 of the entire certificate and pass it to serverCertificateHashes. In fact, now the example does not rely on the CLI argument for chrome anymore but already accepts the self-signed certificate from any chrome instances

[cBournhonesque]

Thanks, I was able to get the certificates work using the master branch! When passing serverCertificateHashes, there's no need to pass command-line args to Chrome?

Btw I was able to compile ring for wasm; it just didn't work out-of-the-box on Mac M1, I had to switch to the llvm clang

[BiagioFesta]

When passing serverCertificateHashes, there's no need to pass command-line args to Chrome?

Exactly, serverCertificateHashes allows you to set which certificates are accepted, so there is no need to pass command-line args to Chrome. And that's how and why I modified example/full.rs of this repository. So users can launch chrome without needing of specifying not-user-friendly arguments with fingerprints.

Also note that serverCertificateHashes is not supported widely: https://caniuse.com/mdn-api_webtransport_webtransport_options_servercertificatehashes_parameter

[BiagioFesta]

This: https://github.com/BiagioFesta/wtransport/pull/120, should help as now Certificate has API for getting sha256 useful for serverCertificateHashes

[MOZGIII]

I think we can close this - https://github.com/cBournhonesque/lightyear is using xwt now :D

[mvlabat]

Is WASM support for wtransport something that's been achieved or why was the issue closed? Is it something that would still make sense to track for this crate?

[BiagioFesta]

WASM support is not planned for this crate at the moment. It is something that's not in the roadmap, for now at least.

However, as mentioned in this issue, xwt provides WASM support as compatibility layer directly with wtransport.