cargo-vet trusted publishers · wasmtime

In our cargo-vet configuration we have a few crates which we have decided we trust without auditing them because we trust the person who publishes them. But there are a few dozen crates which Mozilla has declared they trust and we haven't. We should collectively decide if we want to trust the same people that Mozilla does, without reviewing their code. Here's a rough count of how many crates we could avoid reviewing by following Mozilla's lead:

     11 isrg and mozilla trust Andrew Gallant (BurntSushi)
     11 isrg and mozilla trust David Tolnay (dtolnay)
     10 isrg and mozilla trust Alex Crichton (alexcrichton)
      7 isrg and mozilla trust Amanieu d'Antras (Amanieu)
      6 isrg and mozilla trust Sean McArthur (seanmonstar)
      3 mozilla trusts Ed Page (epage)
      2 mozilla trusts Carl Lerche (carllerche)
      2 mozilla trusts Josh Stone (cuviper)
      1 mozilla trusts Alice Ryhl (Darksonn)
      1 mozilla trusts Matt Brubeck (mbrubeck)

I'm adding this to tomorrow's Wasmtime meeting agenda in case anyone would prefer to discuss it there.

Andrew Brown (Feb 07 2024 at 21:34):

I just ran into an issue with the "trusted crates" idea that I don't understand: in #7846, I trusted the windows crate, which matches the current policy we have for all the windows-* crates. But when we run cargo vet --locked on the branch that uses this, #7807, we still get:

Vetting Failed!

10 unvetted dependencies:
  windows:0.52.0 missing ["safe-to-deploy"]
  windows-core:0.51.1 missing ["safe-to-deploy"]
  windows-targets:0.48.5 missing ["safe-to-deploy"]
  windows_aarch64_gnullvm:0.48.5 missing ["safe-to-deploy"]
  windows_aarch64_msvc:0.48.5 missing ["safe-to-deploy"]
  windows_i686_gnu:0.48.5 missing ["safe-to-deploy"]
  windows_i686_msvc:0.48.5 missing ["safe-to-deploy"]
  windows_x86_64_gnu:0.48.5 missing ["safe-to-deploy"]
  windows_x86_64_gnullvm:0.48.5 missing ["safe-to-deploy"]
  windows_x86_64_msvc:0.48.5 missing ["safe-to-deploy"]

vet: trust the `windows` crates by abrown · Pull Request #7846 · bytecodealliance/wasmtime

Like the rest of the windows-* crates published by Kenny Kerr, this change also adds the windows crate itself to the trusted list. This is necessary for use in #7807.

WinML backend for wasi-nn by jianjunz · Pull Request #7807 · bytecodealliance/wasmtime

This change adds Windows Machine Learning backend for wasi-nn. Since WinML is a built-in feature of Windows, this change makes it possible to run wasi-nn on Windows without a third-party machine le...

Andrew Brown (Feb 07 2024 at 21:35):

Andrew Brown (Feb 07 2024 at 21:40):

I can reproduce this locally on the PR branch, where I observe that indeed the Windows crate is trusted:

[[trusted.windows]]
criteria = "safe-to-deploy"
user-id = 64539 # Kenny Kerr (kennykerr)
start = "2021-01-15"
end = "2025-01-30"

Andrew Brown (Feb 07 2024 at 21:44):

Alex Crichton (Feb 08 2024 at 03:01):

Oh I think you'll need to run cargo vet after adding the trusted entry. Executing that adds new "lock file entries" which need to then get checked in. The trusted entry enables auto-adding new lock entries I believe

Alex Crichton (Feb 08 2024 at 03:02):

if I run cargo vet on the winml branch everything passes but it updates supply-chain/imports.lock which is what --locked is preventing in CI

Andrew Brown (Feb 08 2024 at 21:48):

vet: update lock file for trusted `windows` crates by abrown · Pull Request #7900 · bytecodealliance/wasmtime

In #7846 I added cargo-vet entries to trust the windows crate, just like we already trust several related windows-* crates. I did not, however, update the lockfile, which means that #7807 continued...

Stream: wasmtime

Topic: cargo-vet trusted publishers