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-tlsis quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python'sSSLSocket.version().This PR adds a third backend: OpenSSL. The
opensslcrate exposes a much larger API surface thannative-tlsdoes and will most likely be enough for wasi-tls' future needs.Depending on how restrictive the
wasmtime-wasi-tls-nativetlsimplementation 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+nativetlsorrustls+openssl.
badeend requested wasmtime-wasi-reviewers for a review on PR #12228.
badeend requested abrown for a review on PR #12228.
badeend requested wasmtime-default-reviewers for a review on PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
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-tlsis quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python'sSSLSocket.version().This PR adds a third backend: OpenSSL. The
opensslcrate exposes a much larger API surface thannative-tlsdoes and will most likely be enough for wasi-tls' future needs.Depending on how restrictive the
wasmtime-wasi-tls-nativetlsimplementation 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+nativetlsorrustls+openssl.TODO:
- cargo vet
- get the Windows CI runner to work
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
badeend updated PR #12228.
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-tlsis quickly showing its shortcomings. For example: it can't read the negotiated TLS version, which is needed to implement Python'sSSLSocket.version().This PR adds a third backend: OpenSSL. The
opensslcrate exposes a much larger API surface thannative-tlsdoes and will most likely be enough for wasi-tls' future needs.Depending on how restrictive the
wasmtime-wasi-tls-nativetlsimplementation 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+nativetlsorrustls+openssl.
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-publishgithub user to the crate? I'll accept the invite and add thewasmtime-publishgithub 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)
badeend updated PR #12228.
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-opensslof course
badeend updated PR #12228.
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-opensslof course
alexcrichton submitted PR review:
Did you get the invite?
I did indeed! Should be updated now too.
Looks like a
cargo vetpart remains? Otherwise r=me
alexcrichton commented on PR #12228:
Oh, to clarify, @badeend would you be ok adding the config recommended by
cargo vetto 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
badeend commented on PR #12228:
this is just an infrastructure thing
Just to verify: aside from the placeholder
wasmtime-wasi-tls-opensslcrate, this PR is also adding a brand new dependency ontokio-opensslwhich is not under control of the BA. You want me to vet that as well?
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 themand I suspect that it'd later complain about
tokio-opensslif that were resolved. If you wouldn't mind resolving this error aboutwasmtime-wasi-tls-opensslI'll add the vet fortokio-openssl
Last updated: Jan 09 2026 at 13:15 UTC