wasmtime / PR #12174 feat(p3): implement `wasi:tls` · git-wasmtime

The P2 bindings are built on top of the TlsProvider/TlsTransport/TlsStream abstractions defined in crates/wasi-tls/src/lib.rs. Those abstractions make the bindings agnostic to the actual underlying TLS implementation. Currently, wasmtime has three backends for the user to choose from:

rustls (the default of this wasmtime-wasi-tls crate)

wasmtime-wasi-tls-nativetls

wasmtime-wasi-tls-openssl

The P3 bindings in this PR bypass the existing abstractions and target rustls directly.

Do you think it is possible to make the P3 bindings backend-agnostic as well? Doesn't necessarily have to be part of this PR right now

Wasmtime GitHub notifications bot (Feb 19 2026 at 11:53):

rvolosatovs submitted PR review.

Wasmtime GitHub notifications bot (Feb 19 2026 at 11:53):

rvolosatovs created PR review comment:

That would be awesome!

Wasmtime GitHub notifications bot (Feb 19 2026 at 11:58):

rvolosatovs submitted PR review.

Wasmtime GitHub notifications bot (Feb 19 2026 at 11:58):

rvolosatovs created PR review comment:

I would rather start with the simplest approach using the library directly. It should definitely be possible to abstract the implementation here, however there might be some challenges here, as we can't quite directly use Tokio I/O abstractions here due to the lack of (CM) cancellation support in Tokio.

Let's figure this out in a follow-up?

Wasmtime GitHub notifications bot (Feb 19 2026 at 11:59):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Feb 19 2026 at 11:59):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Feb 19 2026 at 12:04):

rvolosatovs edited PR review comment.

Wasmtime GitHub notifications bot (Feb 19 2026 at 13:02):

badeend submitted PR review.

Wasmtime GitHub notifications bot (Feb 19 2026 at 13:02):

badeend created PR review comment:

Sure :+1:

Wasmtime GitHub notifications bot (Feb 19 2026 at 13:06):

badeend submitted PR review.

Wasmtime GitHub notifications bot (Feb 19 2026 at 13:06):

badeend created PR review comment:

v0.2.0-draft+6781ae2

Wasmtime GitHub notifications bot (Feb 19 2026 at 16:14):

rvolosatovs updated PR #12174.

Wasmtime GitHub notifications bot (Feb 19 2026 at 16:15):

rvolosatovs requested badeend for a review on PR #12174.

Wasmtime GitHub notifications bot (Feb 20 2026 at 19:58):

alexcrichton created PR review comment:

I realize that this is duplicating the p2 tests already present, but given that this is basically modeled as "run the thing" that could also be modeled as a p3_cli_* test run as part of tests/all/cli_tests.rs where it bottoms out in wasmtime run -S... foo.wasm.

I might recommend moving more in that direction than having librarified test here to make it a bit more uniform to run tests

Wasmtime GitHub notifications bot (Feb 20 2026 at 19:58):

alexcrichton created PR review comment:

I'm not sure if this was copied from elsewhere, but personally I'd say that these macros are probably overkill given the that they're mostly one-liners around table.$method(thing) and the type annotations on Resource<T> is typically enough to guide everything type-inference wide. The benefit of these macros would be the extra error context information, but given how rarely these will all be triggered I'm not sure it's worth the complexity.

Wasmtime GitHub notifications bot (Feb 20 2026 at 19:58):

alexcrichton submitted PR review:

I'm finding host/mod.rs pretty gnarly here especially with Waker logic and such to the point that I'd have to dig more into what rustls is offering here to double-check all the logic. That being said I'd also be fine to defer to @badeend in terms of review on that.

I'll note though that this is a pretty beefy implementation with relatively light testing. Would it be possible to enhance the tests here or does the current test basically not pass unless all the bits and bobs are present?

Wasmtime GitHub notifications bot (Feb 22 2026 at 13:31):

badeend submitted PR review.

Wasmtime GitHub notifications bot (Feb 22 2026 at 13:31):

badeend created PR review comment:

The WIT file mentions:

Closing the cleartext stream will cause a close_notify packet to be emitted on the returned output stream.

I don't see where graceful shutdown is handled in the current implementation. I would expect a call to send_close_notify somewhere

Wasmtime GitHub notifications bot (Feb 22 2026 at 13:31):

badeend created PR review comment:

I notice process_new_packets appear multiple times in this file.

The rustls documentation mentions that this method should only be called after a successful call to Connection::read_tls. This lines up with how e.g. tokio-rustls does it, where the term process_new_packets appears only once in the entire crate, right after the call to read_tls.

I think only CiphertextConsumer has to use process_new_packets, and the other ones can get by without:

The returned state variable is used as a heuristic for the capacity of .as_direct(..). A fixed size could work too, optionally bounded by dst.remaining().

peer_has_closed is also surfaced from the regular read call, when it returns Ok(0)

Wasmtime GitHub notifications bot (Feb 22 2026 at 13:31):

badeend created PR review comment:

The wasi-tls create already has a bunch of these types in crates/wasi-tls/src/lib.rs. E.g. WasiTls<'a>, WasiTlsCtx, WasiTlsCtxBuilder. Can the P3 implementation make use of those existing ones?

Wasmtime GitHub notifications bot (Feb 22 2026 at 13:31):

badeend created PR review comment:

connect should perform the handshake and not return before that has succeeded or failed. But in its current form this method doesn't do any I/O.

Wasmtime GitHub notifications bot (Feb 22 2026 at 13:31):

badeend created PR review comment:

The error returned by process_new_packets only affects the read_tls side. The other directions may still continue to work. From rustls docs:

After an error is received from process_new_packets, you should not call read_tls any more (it will fill up buffers to no purpose). However, you may call the other methods on the connection, including write, send_close_notify, and write_tls. Most likely you will want to call write_tls to send any alerts queued by the error and then close the underlying connection.

So I don't know if waking everybody up is the right thing to do.

Last updated: Feb 24 2026 at 06:21 UTC