Not OP but a difference is in who manages the updating of a vendored dep. You don’t want to update every time there’s a release, but you don’t want to never update either.
If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event?
If vendoring just means we periodically pull a copy of upstream into our repo then you can have unbounded time when you don’t know there’s a vuln and therefore haven’t considered whether you need to act.
This is obv different from the situation where we all just cargo install (without —locked) and different from c style dep mgmt where we get sec fixes for many libs via our OS patching.
> If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event?
You still retain the Cargo.toml and Cargo.lock, so the exact same way as if you didn't vendor: `cargo-audit` would inform you, you'd update the version, and re-vendor.
The cargo-audit I referred to in my previous post is that tooling, it's commonly run in CI regularly.
But, also, this is pretty far afield from my original question: I understand why keeping copies of your dependencies can introduce various things you should handle, but my original question was "what is vendoring your dependencies if not 'keeping a copy of the source code of your dependencies in the repository'"? That's my understanding of the definition of "vendoring," so I was curious what my original parents' definition was.
If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event?
If vendoring just means we periodically pull a copy of upstream into our repo then you can have unbounded time when you don’t know there’s a vuln and therefore haven’t considered whether you need to act.
This is obv different from the situation where we all just cargo install (without —locked) and different from c style dep mgmt where we get sec fixes for many libs via our OS patching.