Should wasi-tls be imported in the wasi:cli world?

[ricochet]

Today we do not import wasi:tls in the worlds that we encourage runtimes to support, e.g. wasi:cli/run and wasi:http/proxy.

Should wasi:cli/run remain strictly to features of POSIX or is the intention to provide features that most CLI programs need (including SSL/TLS)? Today sockets are supported but making requests for insecure sockets is (or at least should be) rare.

Some options:

• Add wasi:tls to imports and thus the run world behind a feature gate, e.g. cli-with-tls.
• Introduce another world in wasi:cli, e.g. run-with-tls or cli-secure
• Add a world to the wasi:tls proposal that is essentially the above, wasi:tls/run
• Introduce a different batteries included proposal. I often write programs that import both wasi:cli/imports + wasi:http/outgoing-handler and would depend on wasi:tls once it reaches phase 3 and is well supported by the ecosystem, .e.g cli-net-tls.

[pchickey]

I don't think we're ready to add wasi:tls to the wasi:cli/run world by default yet, but I won't rule it out in the future. Simply put, its a pretty significant burden on top of the existing posix features to require of runtimes, especially given that TLS implementations are historically a source of tricky security issues that would require robust plans to update runtimes when vulnerabilities are discovered.

We can work on getting adoption of wasi:tls by making it available in runtimes and useful in guests before adding it to any of the standardized worlds. Similar to how many guests require wasmtime serve -Scli which has the full set of cli imports on top of the proxy world, wasmtime can add wasmtime [run|serve] -Stls for the users who require these additional imports. The various cloud/service embeddings can also make the imports available (behind a gate, if desired) and as we see adoption happen, then that can better inform what standard worlds it makes sense to add it to.