Update wasi-crypto to the current version

[jedisct1]

This brings the implementation to the current version of the spec.

Supersedes #4612

/cc @rjzak

[fitzgen]

LGTM

[fitzgen]

Er actually I missed that last commit.

I think our policy is not to add new exemptions.

[jedisct1]

Hi Nick,

So, what should be done to make cargo vet not block the merge?

[fitzgen]

I think a Wasmtime committer would have to review all new dependencies and the delta from last review/exemption for any updated dependencies.

[jedisct1]

So, shall I just remove the last commit?

[fitzgen]

So, shall I just remove the last commit?

I think so. And then you or someone else would have to perform audits of the new/updated dependencies.

[jameysharp]

Anything you can do to reduce the changes to Cargo.lock will make the supply-chain review easier. For example, if there are some third-party crates that you can avoid using without compromising too much on anything else, then removing those dependencies will help.

Even for crates that you need to keep, disabling unused features may reduce how many crates they depend on. (I'm not 100% sure that will affect Cargo.lock, but I think so?) In particular I'm guessing turning off the boring feature might make a big difference; I bet crates like cmake are only being pulled in to compile BoringSSL.

[jedisct1]

Unfortunately, there's not much to be removed, and most of these dependencies were already there for the previous version. The post-quantum schemes can be removed, but that wouldn't remove a lot of dependencies.

Note that support for wasi-crypto is not enabled by default in Wasmtime; it is behind a feature flag.

[jameysharp]

I think I remember that when we set up cargo vet, we discussed the possibility of disabling it for certain crates. I feel like wasi-crypto was one of them (and maybe wasi-nn?), but I don't remember if we came to any conclusions.

If I'm reading the manual correctly, I think we can add criteria = [] to the [policy.wasi-crypto] section of supply-chain/config.toml if we want to do that.

Whether we should do that is a bigger policy question. Maybe @alexcrichton or @bholley have opinions on this?

[alexcrichton]

We have arbitrarily drawn a line in the sand awhile back saying "everything here is ok" and are now trying to avoid moving that line in the sand. While wasi-crypto's dependency tree was grandfathered in behind the line in the sand I personally feel that we should hold all new WASI proposals, dependencies, etc, to a higher bar of inclusion, requiring an on-the-record vet entry for everything. Personally I do not think that we should go the route of excluding WASI proposals from the vetting process as I feel that inclusion into the upstream tree here is not a free operation and this is one of the costs.

Note that dependencies do not need to be fully vetted, only the diff from the last known good version, aka the diff from where we drew the line in the sand awhile ago.

[alexcrichton]

I'm going to close this now as wasi-crypto was removed given the discussion in #6732