3 ms·

>Now not only you're not vulnerable to someone pushing malicious code to crates.io Obviously you're only protected against new compromises. If the code is alre

>Now not only you're not vulnerable to someone pushing malicious code to crates.io Obviously you're only protected against new compromises. If the code is already compromised you're screwed (but not worse than using normal downloaded dependencies). This does make it possible that you miss security updates and other important features.

yakubin 5y ago
No. Vendoring doesn't change the picture in that way in Rust at all. Let's go one by one: > Obviously you're only protected against new compromises. Same as in the case of default Rust workflow. Cargo.lock ensures that versions of your dependencies are the same across different machines/devs. > If the code is already compromised you're screwed (but not worse than using normal downloaded dependencies). Yes, I generally read the code of my dependencies, so that's fine. Checking all the digests and crypto ever won't protect me from having to check what I use. > This does make it possible that you miss security updates and other important features. Again. Same as in normal Rust, thanks to Cargo.lock. But I think that's great, because the flip side of it is: I'm also going to miss all the new bugs. I don't want updates to be something that's happening behind my back. I want to check them and do them at the time of my choosing. What vendoring brings to the table is the simplest solution to "is the code on crates.io the same as in the upstream repo", because with vendoring I don't care about the upstream repo at all. I only care about the copy of code that I have in my own repo. Going to GitHub and then checking if digests match would be a very roundabout way to do that, and then over the years people discover flaws in the hash functions etc. etc. I don't bother, I choose not to have to wonder about it at all. I don't care about what's on GitHub, I only care about what's in my own repo. And then again, there are issues of disappearing dependencies, which digests do not solve, but vendoring solves in the simplest way possible. Digests (already incorporated by Cargo by default) only solve someone pushing malicious code; vendoring solves the problem wholesale (assuming that you actually read the code).
- KajMagnus 5y ago
  > assuming that you actually read the code How large percent of the development time, would you say you spend on reading the code in the dependencies? If you would be ok with posting a link to any online repo of yours, then, it'd be interesting to have a look at how many lines of code there are, in the vendored dependencies, and compare with num lines in the actual program. Maybe I'd run `cloc`

yakubin 5y ago

No. Vendoring doesn't change the picture in that way in Rust at all. Let's go one by one: > Obviously you're only protected against new compromises. Same as in the case of default Rust workflow. Cargo.lock ensures that versions of your dependencies are the same across different machines/devs. > If the code is already compromised you're screwed (but not worse than using normal downloaded dependencies). Yes, I generally read the code of my dependencies, so that's fine. Checking all the digests and crypto ever won't protect me from having to check what I use. > This does make it possible that you miss security updates and other important features. Again. Same as in normal Rust, thanks to Cargo.lock. But I think that's great, because the flip side of it is: I'm also going to miss all the new bugs. I don't want updates to be something that's happening behind my back. I want to check them and do them at the time of my choosing. What vendoring brings to the table is the simplest solution to "is the code on crates.io the same as in the upstream repo", because with vendoring I don't care about the upstream repo at all. I only care about the copy of code that I have in my own repo. Going to GitHub and then checking if digests match would be a very roundabout way to do that, and then over the years people discover flaws in the hash functions etc. etc. I don't bother, I choose not to have to wonder about it at all. I don't care about what's on GitHub, I only care about what's in my own repo. And then again, there are issues of disappearing dependencies, which digests do not solve, but vendoring solves in the simplest way possible. Digests (already incorporated by Cargo by default) only solve someone pushing malicious code; vendoring solves the problem wholesale (assuming that you actually read the code).

KajMagnus 5y ago
> assuming that you actually read the code How large percent of the development time, would you say you spend on reading the code in the dependencies? If you would be ok with posting a link to any online repo of yours, then, it'd be interesting to have a look at how many lines of code there are, in the vendored dependencies, and compare with num lines in the actual program. Maybe I'd run `cloc`