4 ms·

This is actually a great outcome. All dependencies are a security risk - the argument for not vendoring every dependency is that you should keep external depend

This is actually a great outcome. All dependencies are a security risk - the argument for not vendoring every dependency is that you should keep external dependencies up to date to avoid known security issues. If the external dependency has nobody watching it any more then that argument disappears, and that external dependency becomes a liability. The fact the dependency was marked as abandoned and started getting flagged in security reports is what you want. That lets you make an informed decision about whether to vendor it (which removes the "bad actor sneaks something in" risk) or do something else. It's great that the Rust build system allows that so easily.

the_mitsuhiko 3y ago
Author here: the result is now that the debt got absorbed into a project that uses the fork exclusively. It’s less likely that folks will look for security issues. It would in my mind have been better for folks to use an abandoned shared library where at the very least if a security incident popped up we would have all been notified and dealt with it at once.
- jerf 3y ago
  The debt has been absorbed and I don't deny that, but it has at least been absorbed in a way that makes paying it locally easier. Given that the description of the problem includes generally not being affected by its issue I read that to be the rather common case in which one is just using a relatively small fraction of the library. To be concrete, let's say it's an image library, and it turns out there's a PNG parsing vulnerability, but your code only ever uses it for GIFs. If you vendor it you also have the opportunity to go in and just yank PNG, JPEG, TIFF, etc. support, and depending on the situation, plugin support (maybe you can trivially tweak your code to go directly to the JPEG support without passing through anything else). I'm not saying this is a perfect solution with no downsides, but it's not all downside either. Of course, you need the aforementioned solid test coverage. Without that you're just flying blind. That's another thing about the debt metaphor... it can compound, but unlike most monetary debt, code debt can compound on you unexpectedly.
actionfromafar 3y ago
Even if it's maintained, you don't know how good it is security wise.
keybored 3y ago
Vendoring a pinned dependency just looks like dependency theater. You can let it sit there as a pinned dependency and it will do just as much harm as if you vendor it. I get the sense (only a sense because the author is a bit coy, but sibling comment by him seems to confirm) that this was more to appease these tools that look for “bad dependencies”.

the_mitsuhiko 3y ago

Author here: the result is now that the debt got absorbed into a project that uses the fork exclusively. It’s less likely that folks will look for security issues. It would in my mind have been better for folks to use an abandoned shared library where at the very least if a security incident popped up we would have all been notified and dealt with it at once.

jerf 3y ago
The debt has been absorbed and I don't deny that, but it has at least been absorbed in a way that makes paying it locally easier. Given that the description of the problem includes generally not being affected by its issue I read that to be the rather common case in which one is just using a relatively small fraction of the library. To be concrete, let's say it's an image library, and it turns out there's a PNG parsing vulnerability, but your code only ever uses it for GIFs. If you vendor it you also have the opportunity to go in and just yank PNG, JPEG, TIFF, etc. support, and depending on the situation, plugin support (maybe you can trivially tweak your code to go directly to the JPEG support without passing through anything else). I'm not saying this is a perfect solution with no downsides, but it's not all downside either. Of course, you need the aforementioned solid test coverage. Without that you're just flying blind. That's another thing about the debt metaphor... it can compound, but unlike most monetary debt, code debt can compound on you unexpectedly.

actionfromafar 3y ago

Even if it's maintained, you don't know how good it is security wise.

keybored 3y ago

Vendoring a pinned dependency just looks like dependency theater. You can let it sit there as a pinned dependency and it will do just as much harm as if you vendor it. I get the sense (only a sense because the author is a bit coy, but sibling comment by him seems to confirm) that this was more to appease these tools that look for “bad dependencies”.