This is getting pretty far from the original problem of random person on the internet yanking their crate.
Right. So let's circle back to that.
Subjectively, when a maintainer yanks their crate, maybe half the time, there's actually some security problem
or defect that might be of interest. But the other half of the time, there's not actually any known
defect or problem with the crate. It's just the crate maintainer "trying to indicate to users that they are no
longer interested in developing this version of the code" or something like this. Generously, that's an example
of something that's "important but not urgent" to downstream -- if the code is working in production, then
there may be little reason to do anything even though the maintainer yanked it.
Less generously, this is essentially noise. And it's noise that's being reported over the same channel as actual
security problems that are actually important and urgent. (Part of the reason that it's noise is that there
simply isn't consensus among the rust community around how yanking is supposed to be used.)
By itself, that would be fine. There are lots of noisy channels in life, and this is just one more of them.
But what makes yanking really pernicious is that this noise is being piped directly into my build system, so
that when cargo build happens, all of this yanking information is going into the build system in ways that
I don't have meaningful visibility or control over.
To me, this just seems bizarre. If I'm working on high-assurance stuff, I want to have visibility and control
over everything that I'm incorporating. I want to be in the loop if there's a security vuln against X that's
detected when I build against master, because it might also affect an earlier release branch. I don't really
want things to be upreved without me opting in -- as responsible downstream, I want to be in the driver seat.
The idea that like, hundreds of random crate maintainers are able yank things at any time, which might somehow
affect my build in a way that I can't easily squelch, and like, a build that worked one way yesterday could
work a different way tomorrow, just feels profoundly uncivilized and not how I would want this to work.
And yes, I get that I can edit lock files manually, and use cargo update --precise, and that it's possible
in principle to work around all this, but like, that is all very tedious and feels like it just shouldn't be
necessary. The contract I need to have here is that downstream decides when things get updated, and the
maintainer's opinion is just one data point.
I don't work at a self-driving car company anymore. All their code was C++, and indeed, they vendored everything
to themselves in a giant internal repository, because they can't tolerate the possibillity that upstream would
delete the release they were using or something. And they were a large company, so they can deal with all the
manual labor that that entails.
Someone approached me once about joining a self-driving plane startup. Suppose I joined a company like that tomorrow.
I would like to advocate for Rust, because it catches a lot of bugs that end up in large C++ projects. But I
would not want to start on day one by doing cargo vendor to like, mirror a whole bunch of crates.io stuff,
because I would want to avoid all the manual labor associated to such flows. We might get to vendoring eventually,
but the way I would want to start is something like, put ignore_yank = true in .cargo/config, and set up
CI so that cargo audit and cargo deny are run, and see how far we get that way until the company is bigger.
I still think it would be better for the ecosystem if we steer people towards filing RUSTSEC advisories rather
than just yanking things with no explanation, and discourage people from yanking unless there is a severe security
defect. Alternatively, if there's a snafu before cargo publish, and the crate doesn't build, may be yanking is
allowed but there is a time limit after which you can't yank, would reduce a lot of noise.
But giving projects a way to ignore yanking information during cargo build, for the users that want
that, is also a reasonable way to help downstream simplify and have more control over the build.
I would even consider forking cargo to add an ignore_yank = true option if I thought it would save me time overall,
it might be a pretty easy patch to develop and carry forward as cargo is updated.
Also testing for miscompilations in self-driving software manually, on the road, is extremely irresponsible!
For all the UB-risking parts you should have automated tests and fuzzing coverage.
Automated tests and fuzzing are great, but they are not a subsitute for end-to-end testing on real hardware.
There are a lot of reasons for this. Exercising the component with random data may not actually match the real
data it sees in production, so you aren't guaranteed to find the bug. If you just fuzz the code on your x86
workstation, you may not actually discover the bug, especially if it's a code-gen issue. But it may be
prohibitively difficult or complicated to instrument the production hardware in a way that you can run a fuzzing
test on the actual hardware.
If I recall correctly, MISRA standards actually require you to perform a certain amount of hours of real-world use,
depending on the impact of the change. So you may be required to have people drive the car for a certain number
of hours, if you are seeking MISRA compliance.