3 ms·

I routinely read code of crates I use (which is placed under ~/.cargo if you do not vendor) and of the Rust standard library (which is placed under ~/.rustup).

I routinely read code of crates I use (which is placed under ~/.cargo if you do not vendor) and of the Rust standard library (which is placed under ~/.rustup). It's usually the fastest way to figure out how something works, since Googling/Stack Overflow will usually result in a lot of related, but not really applicable answers, and some incorrect ones. As for supply-chain issues, I just vendor my dependencies. Problem solved. Just run cargo vendor and copy stdout to .cargo/config.toml in your project. Done. Now not only you're not vulnerable to someone pushing malicious code to crates.io, but also have one place where all the dependencies of your project have their source code available to read for you. If you archive your project and then want to get back to it after years on another computer which did not have the dependencies installed, you don't need to hunt on the internet for dependencies that don't exist anymore[1]. If you want to work on a project without an Internet connection, all you need is the repo, you don't need to worry if a given computer has all the dependencies installed in the right versions. If crates.io ever goes down, or they take down a crate, you're safe as well. Although it's not the default in Rust, it's very well supported by cargo, if you want to develop in this model. [1]: Yes, those are my bad experiences with Python dependencies.

rat87 5y ago
> If you archive your project and then want to get back to it after years on another computer which did not have the dependencies installed, you don't need to hunt on the internet for dependencies that don't exist anymore[1]. Rust doesn't yank things though, except for legal reasons so taht shouldn't happen(assuming you're getting a crate from crates.io not a random github link)
sour-taste 5y ago
>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`

rat87 5y ago

> If you archive your project and then want to get back to it after years on another computer which did not have the dependencies installed, you don't need to hunt on the internet for dependencies that don't exist anymore[1]. Rust doesn't yank things though, except for legal reasons so taht shouldn't happen(assuming you're getting a crate from crates.io not a random github link)

sour-taste 5y ago

>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`