Adding new crates to a workspace and forgetting audit-as-crates-io

[alexcrichton]

Over in Wasmtime I've noticed some odd behavior around cargo vet which I think can probably be attributed to forgetting to add new entries with audit-as-crates-io. I am not 100% certain of this sequence of events, but I think the rough shape of what we're seeing is:

1. Add a new crate to the workspace, for example in our case let's say wasmtime-foo. This crate isn't published on crates.io yet. No cargo-vet changes are recorded for this crate.
2. Eventually a release branch is created for, say release-20.0.0. This means that on the release branch wasmtime-foo is at 20.0.0 and on main it's 21.0.0
3. The release-20.0.0 branch is released, meaning that crates.io now has 20.0.0.

• Here if you have a fresh install and run cargo vet on main it appears that cargo vet well generate an error recommending audit-as-crates-io
• If you have a fresh install and run cargo vet --locked on main then this succeeds
• If you have a "dirty install" where you were previously doing cargo vet things locally, this does not error out on main. Removing ~/.cache/cargo-vet causes the error to show up.

4. CI continues to pass on main and release-20.0.0 because cargo vet --locked works.

We appear to be wedging ourself into a state where CI is always passing at all times but in the future cargo vet fails by default locally. This failure doesn't happen for everyone as it appears to be dependent on ~/.cache/cargo-vet state as well. I apologize in that I have not done a precise reproduction of all the steps above because it seems to require interaction with publishing crates on crates.io. I'm trying to describe various failures and confusing behaviors we've seen in Wasmtime CI and locally as best I can, but I can also try to provide more information if that'd help.

[mystor]

The caching of the non-published status of crates is somewhat intentional to avoid spamming crates.io with requests every time a cargo vet command is run, which unfortunately led to this situation. We did set the expiry time for nonexistant crate checks fairly long (60 days) which perhaps was a mistake. I think it could make sense to shorten it, but that still leads to this problem just with a shorter timeframe before things start working as expected.

I don't think there's a great way for us to immediately detect that a crate has been published without checking crates.io every time unfortunately, unless cargo leaves some kind of paper trail for us to detect. It might be possible to notice the crate in the local cargo cache, but we've been avoiding depending on that since there are now multiple formats and such with the https crates.io registry changes. Perhaps the new setup is now stable enough that it's OK to give that a shot.