Stream: git-wasmtime

Topic: wasmtime / issue #5271 Update wasi-crypto to the current ...

Wasmtime GitHub notifications bot (Nov 15 2022 at 18:33):

jedisct1 commented on issue #5271:

Hi Nick,

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

Wasmtime GitHub notifications bot (Nov 15 2022 at 18:35):

fitzgen commented on issue #5271:

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

Wasmtime GitHub notifications bot (Nov 15 2022 at 18:40):

jedisct1 commented on issue #5271:

So, shall I just remove the last commit?

Wasmtime GitHub notifications bot (Nov 15 2022 at 18:52):

fitzgen commented on issue #5271:

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.

Wasmtime GitHub notifications bot (Nov 15 2022 at 19:06):

jameysharp commented on issue #5271:

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.

Wasmtime GitHub notifications bot (Nov 15 2022 at 19:13):

jedisct1 commented on issue #5271:

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.

Wasmtime GitHub notifications bot (Nov 15 2022 at 19:30):

jameysharp commented on issue #5271:

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?

Wasmtime GitHub notifications bot (Nov 15 2022 at 22:05):

alexcrichton commented on issue #5271:

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.

Last updated: Nov 22 2024 at 17:03 UTC