I'm at a point where I need to at least vent a bit of frustration with cargo vet
. As time goes on I feel like we know less and less of how cargo vet
works and it becomes more and more of a black box that everyone just punts questions to someone else for. I also feel like if I can't figure out how to get something working with cargo vet
then it just doesn't get done and we have to work around it one way or another, which isn't a great feeling for me as I'm generally just as much in the dark about others when it comes to cargo vet
.
In the immediate term I have no idea why this PR is failing for cargo vet
. If I run the CI commands locally I can't get the same failure. The PR changes supply-chain/*.toml
files which seems highly likely to be relevant but if I revert the changes locally and run cargo vet
then it changes the files again. I can't figure out what the difference is.
Additionally in that PR I'm adding a new crate which I'm now dreading because I know it's going to cause issues in the future. We have a common issue where cargo vet
is going to pass until that crate is published. Once it's published it's going to break our CI on main
and there's nothing we can do about it. We can't add annotations now because it's not published, and it's not published because it has to land in-tree first.
Overall I'm personally relatively frustrated with cargo vet
in that it's a really great property to have for the project and I don't want to give it up but I feel like it's always suffered from key usability issues that haven't gotten resolved. Forcibly breaking our CI every time we add a new crate is quite bad IMO and we've had a relatively long history of being unable to reproduce CI issues locally. I suspect I'm missing something here but everything is so opaque I have no idea where to start to figure out what the difference is.
I'm going to try to hack around the failure in my PR, but it means I'm about to check in a state to the repo where if anyone runs cargo vet
locally then it just breaks and can't land the PR (the same state that PR is in). Doesn't feel great
It might be worth re-evaluating the assumptions we made at the time we adopted the tool, too: the idea was that there would be a shared effort in vetting and that the burden would be relatively minimal. Could we take an objective look at that -- has it happened, how many vets have we had to do, what's the opportunity cost (which features, PRs, ... have we declined because they would bring in more vetting overhead), etc. Good topic for next Wasmtime meeting?
fwiw, the last few dep updates I've done haven't run into any issues with cargo vet
but you also do that kind of thing way more than I do
I don't personally want to champion anything to say we should remove the tool, but I also at the same time don't think we're in a great spot. I do think that factually we haven't really been doing many vets relative to the amount of time we've been using cargo vet
it is probably worth filing an issue upstream and seeing what they have to say
Personally I find it difficult to talk about issues with cargo vet
because everything is so unclear, the (reasonable) knee-jerk reaction is "well how can we fix that problem" and I can't even articulate what the problem is really
I filed an issue awhile ago for the major issue we have (a new great guarantees a CI break in the future), lemme find it
I do think it is a really important part of our overall security story, so I'd much prefer working with upstream to resolve issues than giving it up
https://github.com/mozilla/cargo-vet/issues/604
my impression is that development on cargo-vet has slowed down a lot
yeah :-/
Last updated: Dec 23 2024 at 13:07 UTC