490d49a768
* Adjust dependency directives between crates This commit is a preparation for the release process for Wasmtime. The specific changes here are to delineate which crates are "public", and all version requirements on non-public crates will now be done with `=A.B.C` version requirements instead of today's `A.B.C` version requirements. The purpose for doing this is to assist with patch releases that might happen in the future. Patch releases of wasmtime are already required to not break the APIs of "public" crates, but no such guarantee is given about "internal" crates. This means that a patch release runs the risk, for example, of breaking an internal API. In doing so though we would also need to release a new major version of the internal crate, but we wouldn't have a great hole in the number scheme of major versions to do so. By using `=A.B.C` requirements for internal crates it means we can safely ignore strict semver-compatibility between releases of internal crates for patch releases, since the only consumers of the crate will be the corresponding patch release of the `wasmtime` crate itself (or other public crates). The `publish.rs` script has been updated with a check to verify that dependencies on internal crates are all specified with an `=` dependency, and dependnecies on all public crates are without a `=` dependency. This will hopefully make it so we don't have to worry about what to use where, we just let CI tell us what to do. Using this modification all version dependency declarations have been updated. Note that some crates were adjusted to simply remove their `version` requirement in cases such as the crate wasn't published anyway (`publish = false` was specified) or it's in the `dev-dependencies` section which doesn't need version specifiers for path dependencies. * Switch to normal sever deps for cranelift dependencies These crates will now all be considered "public" where in patch releases they will be guaranteed to not have breaking changes.
wasmtime-wasi-crypto
This crate enables support for the wasi-crypto APIs in Wasmtime.
The sole purpose of the implementation is to allow bindings and application developers to test the proposed APIs. This implementation is not meant to be used in production. Like the specification, it is currently experimental and its functionality can quickly change.
Since the wasi-crypto API is expected to be an optional feature of WASI, this crate is currently separate from the wasi-common crate.
Wasmtime integration
Use the Wasmtime APIs to instantiate a Wasm module and link the
wasi-crypto modules as follows:
use wasmtime_wasi_crypto::{
WasiCryptoAsymmetricCommon, WasiCryptoCommon, WasiCryptoCtx, WasiCryptoSignatures,
WasiCryptoSymmetric,
};
let cx_crypto = WasiCryptoCtx::new();
WasiCryptoCommon::new(linker.store(), cx_crypto.clone()).add_to_linker(linker)?;
WasiCryptoAsymmetricCommon::new(linker.store(), cx_crypto.clone()).add_to_linker(linker)?;
WasiCryptoSignatures::new(linker.store(), cx_crypto.clone()).add_to_linker(linker)?;
WasiCryptoSymmetric::new(linker.store(), cx_crypto.clone()).add_to_linker(linker)?;
let wasi = wasmtime_wasi::old::snapshot_0::Wasi::new(linker.store(), mk_cx()?);
wasi.add_to_linker(linker)?;
Building Wasmtime
Wasmtime must be compiled with the wasi-crypto feature flag
(disabled by default) in order to include the crypto APIs.
Examples
Example rust bindings and assemblyscript bindings are provided to demonstrate how these APIs can be used and exposed to applications in an idiomatic way.