2 ms·

> You hear there's this big vuln affecting Go programs. This isn't relevant. What's relevant is if any of the specific programs I am responsible for have a vul

> You hear there's this big vuln affecting Go programs. This isn't relevant. What's relevant is if any of the specific programs I am responsible for have a vulnerability. If so, I need to update those specific programs. The notion of implementation language, shared library, dependency, these are all abstraction leaks. The atomic unit of responsibility, at the machine level, is program/service.

kelnos 4y ago
I think that's the parent's point. The hypothetical big announcement that this hypothetical "Log4Go" library has a vulnerability will not include a comprehensive list of all applications that use the library, so then we have to hope that the developers of every single application that uses Log4Go hears about the vulnerability, updates their software, makes a new release, and then notifies all their users somehow. Alternatively, a more-savvy user has to hear about this Log4Go vulnerability and see if any of their applications use it and might need an update (which might involve contacting the maintainer to inform them that they need to update their software). But the vast majority of users aren't even going to hear about the Log4Go vulnerability, let alone understand what it means or what they need to do to protect themselves. The safest thing would be for every application to dynamically link to a system-provided version of Log4Go, and OS maintainers would be the ones to send out an update via their OS's auto-update service. This does create other problems, but at least they are problems that technically-unsophisticated users do not need to solve or concern themselves with. (Of course, there is no mechanism to do this with Go modules, so the entire thing is moot.) This is why I get annoyed when developers say "I have to vendor library X into my application, because I'm afraid that the system copy will get updated to a version that breaks my app". Well then, maybe you shouldn't use a library whose author can't abide by semver and provide a reasonably-strong promise that minor and patch version updates won't break things. Otherwise you are just outsourcing your problems to your users.
- preseinger 4y ago
  > The hypothetical big announcement that this hypothetical "Log4Go" library has a vulnerability will not include a comprehensive list of all applications that use the library, Nor should it. A dependency should be encapsulated by its consumers. A vulnerability that leaks to the consumer application is a bug in the consumer application. > The safest thing would be for every application to dynamically link to a system-provided version of Log4Go, Unfortunately this means that any application which uses Log4Go cannot make any definitive assertions about the specific code which is executed by their distributed artifact. This is a problem, and the cost of this problem is far higher than the benefits conveyed by dynamic linking. The future of application distribution is absolutely static linking. > "I have to vendor library X into my application, because I'm afraid that the system copy will get updated to a version that breaks my app". Well then, maybe you shouldn't use a library whose author can't abide by semver and provide a reasonably-strong promise that minor and patch version updates won't break things. Otherwise you are just outsourcing your problems to your users. As a software producer, it should not be possible for a dependency to impact my users without my knowledge. It is infeasible to rely on any specific level of versioning stability from my dependencies. Every dependency I adopt represents a risk which I am taking on.

kelnos 4y ago

I think that's the parent's point. The hypothetical big announcement that this hypothetical "Log4Go" library has a vulnerability will not include a comprehensive list of all applications that use the library, so then we have to hope that the developers of every single application that uses Log4Go hears about the vulnerability, updates their software, makes a new release, and then notifies all their users somehow. Alternatively, a more-savvy user has to hear about this Log4Go vulnerability and see if any of their applications use it and might need an update (which might involve contacting the maintainer to inform them that they need to update their software). But the vast majority of users aren't even going to hear about the Log4Go vulnerability, let alone understand what it means or what they need to do to protect themselves. The safest thing would be for every application to dynamically link to a system-provided version of Log4Go, and OS maintainers would be the ones to send out an update via their OS's auto-update service. This does create other problems, but at least they are problems that technically-unsophisticated users do not need to solve or concern themselves with. (Of course, there is no mechanism to do this with Go modules, so the entire thing is moot.) This is why I get annoyed when developers say "I have to vendor library X into my application, because I'm afraid that the system copy will get updated to a version that breaks my app". Well then, maybe you shouldn't use a library whose author can't abide by semver and provide a reasonably-strong promise that minor and patch version updates won't break things. Otherwise you are just outsourcing your problems to your users.

preseinger 4y ago
> The hypothetical big announcement that this hypothetical "Log4Go" library has a vulnerability will not include a comprehensive list of all applications that use the library, Nor should it. A dependency should be encapsulated by its consumers. A vulnerability that leaks to the consumer application is a bug in the consumer application. > The safest thing would be for every application to dynamically link to a system-provided version of Log4Go, Unfortunately this means that any application which uses Log4Go cannot make any definitive assertions about the specific code which is executed by their distributed artifact. This is a problem, and the cost of this problem is far higher than the benefits conveyed by dynamic linking. The future of application distribution is absolutely static linking. > "I have to vendor library X into my application, because I'm afraid that the system copy will get updated to a version that breaks my app". Well then, maybe you shouldn't use a library whose author can't abide by semver and provide a reasonably-strong promise that minor and patch version updates won't break things. Otherwise you are just outsourcing your problems to your users. As a software producer, it should not be possible for a dependency to impact my users without my knowledge. It is infeasible to rely on any specific level of versioning stability from my dependencies. Every dependency I adopt represents a risk which I am taking on.