Stream: git-wasmtime

Topic: wasmtime / PR #12228 wasi-tls: Add OpenSSL backend


view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 14:11):

badeend opened PR #12228 from badeend:openssl to bytecodealliance:main:

Wasmtime currently supports two wasi-tls providers: rustls & native-tls.

Having multiple backend implementations in a single place helps with being able to quickly iterate on the WIT interface and validate that we're not codifying some rustls-specific behavior/feature into the spec.

@rvolosatovs is looking at implementing wasi-tls for Python. But as predicted, native-tls is quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python's SSLSocket.version().

This PR adds a third backend: OpenSSL. The openssl crate exposes a much larger API surface than native-tls does and will most likely be enough for wasi-tls' future needs.

Depending on how restrictive the wasmtime-wasi-tls-nativetls implementation ends up being, we might consider removing it altogether. For the time being it still works fine, so I've kept it.

What matters to me is that we can demonstrate having two distinct TLS implementations working on all the three major platforms. As long as that criteria is being satisfied, I don't think it really matters whether that's rustls+nativetls or rustls+openssl.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 14:11):

badeend requested wasmtime-wasi-reviewers for a review on PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 14:11):

badeend requested abrown for a review on PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 14:11):

badeend requested wasmtime-default-reviewers for a review on PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 16:29):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 16:34):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 16:47):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 18:33):

badeend edited PR #12228:

Wasmtime currently supports two wasi-tls providers: rustls & native-tls.

Having multiple backend implementations in a single place helps with being able to quickly iterate on the WIT interface and validate that we're not codifying some rustls-specific behavior/feature into the spec.

@rvolosatovs is looking at implementing wasi-tls for Python. But as predicted, native-tls is quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python's SSLSocket.version().

This PR adds a third backend: OpenSSL. The openssl crate exposes a much larger API surface than native-tls does and will most likely be enough for wasi-tls' future needs.

Depending on how restrictive the wasmtime-wasi-tls-nativetls implementation ends up being, we might consider removing it altogether. For the time being it still works fine, so I've kept it.

What matters to me is that we can demonstrate having two distinct TLS implementations working on all the three major platforms. As long as that criteria is being satisfied, I don't think it really matters whether that's rustls+nativetls or rustls+openssl.

TODO:

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 18:43):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 18:48):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 19:28):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 19:43):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 19:45):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 19:48):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 19:54):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 20:01):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 20:18):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 21:15):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 21:20):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 21:38):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 29 2025 at 22:14):

badeend edited PR #12228:

Wasmtime currently supports two wasi-tls providers: rustls & native-tls.

Having multiple backend implementations in a single place helps with being able to quickly iterate on the WIT interface and validate that we're not codifying some rustls-specific behavior/feature into the spec.

@rvolosatovs is looking at implementing wasi-tls for Python. But as predicted, native-tls is quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python's SSLSocket.version().

This PR adds a third backend: OpenSSL. The openssl crate exposes a much larger API surface than native-tls does and will most likely be enough for wasi-tls' future needs.

Depending on how restrictive the wasmtime-wasi-tls-nativetls implementation ends up being, we might consider removing it altogether. For the time being it still works fine, so I've kept it.

What matters to me is that we can demonstrate having two distinct TLS implementations working on all the three major platforms. As long as that criteria is being satisfied, I don't think it really matters whether that's rustls+nativetls or rustls+openssl.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 15:37):

alexcrichton commented on PR #12228:

Thanks for this! (also thanks for wrangling CI here...)

For the remaining checks -- could you publish a placeholder crate and invite the wasmtime-publish github user to the crate? I'll accept the invite and add the wasmtime-publish github team too.

For the vets, would it be possible to update the lock file to retain the slightly older versions of openssl/openssl-sys? Or are the new versions required? (not hard to vet but if it can be deferred might as well)

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:51):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:58):

badeend commented on PR #12228:

(also thanks for wrangling CI here...)

It only took 14 attempts :zany_face:

could you publish a placeholder crate and invite the wasmtime-publish github user to the crate?

I've created the crate and added wasmtime-publish. Did you get the invite?

would it be possible to update the lock file to retain the slightly older versions of openssl/openssl-sys?

Yes! See latest commit. That still leaves tokio-openssl & wasmtime-wasi-tls-openssl of course

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:03):

badeend updated PR #12228.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:05):

badeend edited a comment on PR #12228:

(also thanks for wrangling CI here...)

It only took 14 attempts :zany_face:

could you publish a placeholder crate and invite the wasmtime-publish github user to the crate?

I've created the crate and added wasmtime-publish. Did you get the invite?

would it be possible to update the lock file to retain the slightly older versions of openssl/openssl-sys?

Yes! ~See latest commit.~ That still leaves tokio-openssl & wasmtime-wasi-tls-openssl of course

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:07):

alexcrichton submitted PR review:

Did you get the invite?

I did indeed! Should be updated now too.

Looks like a cargo vet part remains? Otherwise r=me

view this post on Zulip Wasmtime GitHub notifications bot (Jan 07 2026 at 18:15):

alexcrichton commented on PR #12228:

Oh, to clarify, @badeend would you be ok adding the config recommended by cargo vet to get that clean? We try to have maintainers do the actual vets but this is just an infrastructure thing so it's fine for anyone to edit the files

view this post on Zulip Wasmtime GitHub notifications bot (Jan 07 2026 at 18:35):

badeend commented on PR #12228:

this is just an infrastructure thing

Just to verify: aside from the placeholder wasmtime-wasi-tls-openssl crate, this PR is also adding a brand new dependency on tokio-openssl which is not under control of the BA. You want me to vet that as well?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 07 2026 at 18:47):

alexcrichton commented on PR #12228:

Oh sorry I forgot about that, I was going off the CI failure as:

ERROR   × There are some issues with your policy.audit-as-crates-io entries

Error:   × Some non-crates.io-fetched packages match published crates.io versions
     wasmtime-wasi-tls-openssl:42.0.1
  help: Add a `policy.*.audit-as-crates-io` entry for them

and I suspect that it'd later complain about tokio-openssl if that were resolved. If you wouldn't mind resolving this error about wasmtime-wasi-tls-openssl I'll add the vet for tokio-openssl


Last updated: Jan 09 2026 at 13:15 UTC