I am writing this issue since I think it is the better place to ask than my question at Zulip.
I was looking at wasi-common's sync crate feature and it seems to be depending on wasmtime as dependency.
I found this to be weird and checked out the repository locally and just removed the feature dependency line in the Cargo.toml after not really seeing any real dependency on Wasmtime in the sync specific code at first glace. Everything still compiled with cargo build -p wasi-common --no-default-features --features sync.
Is this simply outdated? It would be great if other WASI runtimes (such as Wasmi) could use wasi-common with its sync feature to enable WASI and drop the heavily outdated wasi-cap-std-sync crate entirely.
This is especially important for Wasmi since for technical reasons Wasmi has to use the super outdated v2.0.0 of wasi-cap-std-sync crate and dependabot recently turned my attention to a security issue with atty that is used by wasi-cap-std-sync version v2.0.0.
I am writing this issue since I think it is the better place to ask than my question at Zulip.
I was looking at
wasi-common
'ssync
crate feature and it seems to be depending onwasmtime
as dependency.I found this to be weird and checked out the repository locally and just removed the feature dependency line in the
Cargo.toml
after not really seeing any real dependency on Wasmtime in thesync
specific code at first glace. Everything still compiled withcargo build -p wasi-common --no-default-features --features sync
.Is this simply outdated? It would be great if other WASI runtimes (such as Wasmi) could use
wasi-common
with itssync
feature to enable WASI and drop the heavily outdatedwasi-cap-std-sync
crate entirely.This is especially important for Wasmi since for technical reasons Wasmi has to use the super outdated
v2.0.0
ofwasi-cap-std-sync
crate anddependabot
recently turned my attention to a security issue withatty
that is used bywasi-cap-std-sync
versionv2.0.0
.