5 ms·

> implies taking on responsibility You use a library, you've already taken on responsibility for it. You're application has bugs due to bugs in a library, you'

> implies taking on responsibility You use a library, you've already taken on responsibility for it. You're application has bugs due to bugs in a library, you're users aren't going to accept "we reported it to the library and they said it wasn't important" as the resolution.

AnthonyMouse 6y ago
At which point you either submit a patch to the library or switch to a different library. That much of the work isn't avoidable, except maybe by choosing a better library at the outset. But having to fix it yourself when the library maintainers fail once is a far cry from having to backport every security update in every library yourself even if the library maintainers are properly doing it for a newer version than you're using. The problem is that doing the backporting is typically more work than updating your software to use the newer version of the library, but not maintaining the library version you use at all is invisible in the way that security vulnerabilities are until somebody exploits them.
- eikenberry 6y ago
  Vendoring libraries isn't really different from keeping a version lock file around. You need to review and update the dependencies regularly and monitor them for security issues. Only difference is that instead of a file with the versions you have the full libraries. I personally don't like to vendor as it bloats the revision control system, but as far as dealing with bugs in the dependencies it doesn't really make a difference.
  - AnthonyMouse 6y ago
    > Vendoring libraries isn't really different from keeping a version lock file around. You need to review and update the dependencies regularly and monitor them for security issues. Only difference is that instead of a file with the versions you have the full libraries. In the first case, using a version lock with dynamic linking, the maintainer of the library package is the one paying attention to and shipping patches for the library. And if the version of the library you're using stops being supported, your software breaks and you have to fix it immediately. That's the thing vendoring "makes easier" -- you're not dependent on the third party to maintain that library version. Except that now it's on you to do it, and the breakage that would have told you that the version you're still using may no longer be secure is now absent. So the developer has to pay more attention. Which they regularly do not.

AnthonyMouse 6y ago

At which point you either submit a patch to the library or switch to a different library. That much of the work isn't avoidable, except maybe by choosing a better library at the outset. But having to fix it yourself when the library maintainers fail once is a far cry from having to backport every security update in every library yourself even if the library maintainers are properly doing it for a newer version than you're using. The problem is that doing the backporting is typically more work than updating your software to use the newer version of the library, but not maintaining the library version you use at all is invisible in the way that security vulnerabilities are until somebody exploits them.

eikenberry 6y ago
Vendoring libraries isn't really different from keeping a version lock file around. You need to review and update the dependencies regularly and monitor them for security issues. Only difference is that instead of a file with the versions you have the full libraries. I personally don't like to vendor as it bloats the revision control system, but as far as dealing with bugs in the dependencies it doesn't really make a difference.
- AnthonyMouse 6y ago
  > Vendoring libraries isn't really different from keeping a version lock file around. You need to review and update the dependencies regularly and monitor them for security issues. Only difference is that instead of a file with the versions you have the full libraries. In the first case, using a version lock with dynamic linking, the maintainer of the library package is the one paying attention to and shipping patches for the library. And if the version of the library you're using stops being supported, your software breaks and you have to fix it immediately. That's the thing vendoring "makes easier" -- you're not dependent on the third party to maintain that library version. Except that now it's on you to do it, and the breakage that would have told you that the version you're still using may no longer be secure is now absent. So the developer has to pay more attention. Which they regularly do not.