Open cipriancraciun opened 9 months ago
Hey, this looks good and I'd be happy to merge! Could you also include a small example with build & runtime instructions as well?
Sure, I can add some minimal documentation, but where should this be added? (The README doesn't seem the right place.)
However, please note that there isn't anything specific to supporting WASM WASI (for someone using russh
as a dependency), as one can only run cargo build --target wasm32-wasi
and that's it. The resulting binary can then be run with either wasmtime
or wasmer
as simple as wasmtime run ./target/debug/my-tool.wasm
.
(I'll try to see if perhaps one of the server examples can't be easily run via WASM WASI.)
BTW, the diff I mentioned earlier only actually adds support for "building" russh
on the WASM target. To actually have it do useful stuff, I would like to submit some additional patches (as a different issue / pull request) that add support for interacting with the server / client / agent over stdio
instead of TCP or UNIX sockets. (Because UNIX sockets aren't supported by WASI, and for full sandboxing and security TCP isn't advisable.)
Sorry, I just have limited experience with WebAssembly and even less with WASI. If the existing echoserver example can be directly compiled and run with wasmtime, then I think there's nothing to document :) (IIRC networking used to be just a draft spec in WASI)
As the title says, it would be nice to be able to compile
russh
for the WASI target (i.e. to WASM32 and run it afterwards viawasmtime
orwasmer
).What would be the use-case for WASI:
inetd
(orsystemd
via socket activation) and then run via a WASI runtime; thus the whole SSH server is sandboxed and only has access to what the user allows; (think about implementing some TUI games that the user connects via SSH;)Now, if such a feature would be accepted, I've already patched the
russh
code as per, and I could open a pull request:https://github.com/cipriancraciun/russh/compare/upstream...patches/wasi
The changes are quite minimal in places, and a bit more involved for
russh-config
, namely:tokio
runtime doesn't support thenet
feature for thewasi
target; only for thetarget_os="wasi"
I instructcargo
to use thetokio_wasi
crate (already in Crates, and maintained by https://github.com/WasmEdge); (oncetokio
would support thenet
feature, then this patch can be reverted;)russh-config
the patch is more involved as it has to remove (conditionally based on#[cfg]
) the support forProxyCommand
forwasi
(WASI doesn't yet support process spawning);russh-cryptovec
is patched to have "NOP" implementation formlock
/munlock
, operations that are not supported by WASI.Outside of these changes, nothing else needs to be touched.