3 ms·

> nearly every Go project in the world having to be patched and recompiled Is that a particular problem? What's the difficulty with recompiling?

0xbadcafebee 4y ago
Imagine you are a random person in charge of a computer. You hear there's this big vuln affecting Go programs. 1. How do I find out which programs on my system are Go programs? I have a lot of programs scattered all over. Someone will have to come up with a method (probably search through $PATH for files, run `strings` on it, grep for "Go", pray that's enough) to identify them. 2. They don't list a website, so I have to google the name of every program and find their website. 3. How do I tell which ones are affected by the vuln? I can hope their websites tell me, but maybe they're no longer maintained, or they haven't updated their READMEs. 4. If they don't provide a patched version (most probably won't), I might have to upgrade, which may break things (probably will), assuming they even have an upgradeable version that isn't affected. 5. If I can't upgrade and have to patch, am I even a software developer and know how to do that? 6. If I luckily happen to be one, what system compiled this app 8 years ago, with what dependencies, with what version of Go, etc? Can I recreate that system and learn their build tools to finally patch & recompile? (I am not a Go developer and it has taken me days to figure out how to get different Go programs to compile, for reasons I don't understand) 7. Once I apply the patch how do I test it? (Log4j had multiple iterations of patches/mitigations, some didn't work) If I can't find the source code, can't upgrade it, & can't patch it, I am just stuck with a vulnerable version until I can somehow replace the program. For the programs I was able to identify as vulnerable, anyway. Log4j was "easy" compared to this, because you could just find all the jars on your system and unzip them, find a file, replace it, zip it back up. Log4j was actually a nightmare though, and Go apps will be worse.
- chrisseaton 4y ago
  > How do I find out which programs on my system are Go programs? Well how are these programs getting onto your system? Presumably via some package manager, or an image builder? Don't those manage the update for you? If you're running code that you don't know who wrote, with no source code, that you can't patch, that nobody is taking responsibility for, then yeah you've got issues. But you had issues already if that's the predicament you're in. Some of this applies to Java too - obfuscation breaks the fixes you described using!
  - 0xbadcafebee 4y ago
    Most people download and install Go programs by hand since they're statically compiled, it's their main selling point > If you're running code that you don't know who wrote, with no source code, that you can't patch, that nobody is taking responsibility for, then yeah you've got issues 25 million computers around the world still use Windows XP. It was launched 21 years ago, EOL 8 years ago. Very common actually, especially since most software in the world is not open source. People just keep using software that works.
  - kelnos 4y ago
    > If you're running code that you don't know who wrote, with no source code, that you can't patch, that nobody is taking responsibility for, then yeah you've got issues. This is the default state of affairs for nearly everyone who uses a computer. We can either throw our hands up and futilely say "well they shouldn't do that!", or we can try to solve the problem.
- preseinger 4y ago
  > 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.
SomeCallMeTim 4y ago
The advantage of being able to build to a binary is that you can then distribute the binary directly instead of distributing source and forcing people to rebuild it. When 98% of your users only have the binary and not the source code it means 98% of your users won't even be aware that they need a new version that isn't vulnerable. Remember the vulnerability disclosure will be something like "Log4Go has a vulnerability!!", not that the binary apps you've downloaded have a vulnerability. So if it affects 200 projects, every one of those projects will also have to publish vulnerability notifications independently. And frankly 80% of those projects will likely be abandoned or at least neglected after a couple of years, leaving many people with vulnerable binaries they don't even know to check for vulnerabilities. In other words, they very advantage of Go (easy to distribute binaries directly!) is a security disadvantage. If you instead installed the app using a package manager, the package manager could at least notify you that you have a package with a security issue. But that's nothing new; security and ease-of-use are often at odds.

0xbadcafebee 4y ago

Imagine you are a random person in charge of a computer. You hear there's this big vuln affecting Go programs. 1. How do I find out which programs on my system are Go programs? I have a lot of programs scattered all over. Someone will have to come up with a method (probably search through $PATH for files, run `strings` on it, grep for "Go", pray that's enough) to identify them. 2. They don't list a website, so I have to google the name of every program and find their website. 3. How do I tell which ones are affected by the vuln? I can hope their websites tell me, but maybe they're no longer maintained, or they haven't updated their READMEs. 4. If they don't provide a patched version (most probably won't), I might have to upgrade, which may break things (probably will), assuming they even have an upgradeable version that isn't affected. 5. If I can't upgrade and have to patch, am I even a software developer and know how to do that? 6. If I luckily happen to be one, what system compiled this app 8 years ago, with what dependencies, with what version of Go, etc? Can I recreate that system and learn their build tools to finally patch & recompile? (I am not a Go developer and it has taken me days to figure out how to get different Go programs to compile, for reasons I don't understand) 7. Once I apply the patch how do I test it? (Log4j had multiple iterations of patches/mitigations, some didn't work) If I can't find the source code, can't upgrade it, & can't patch it, I am just stuck with a vulnerable version until I can somehow replace the program. For the programs I was able to identify as vulnerable, anyway. Log4j was "easy" compared to this, because you could just find all the jars on your system and unzip them, find a file, replace it, zip it back up. Log4j was actually a nightmare though, and Go apps will be worse.

chrisseaton 4y ago
> How do I find out which programs on my system are Go programs? Well how are these programs getting onto your system? Presumably via some package manager, or an image builder? Don't those manage the update for you? If you're running code that you don't know who wrote, with no source code, that you can't patch, that nobody is taking responsibility for, then yeah you've got issues. But you had issues already if that's the predicament you're in. Some of this applies to Java too - obfuscation breaks the fixes you described using!
- 0xbadcafebee 4y ago
  Most people download and install Go programs by hand since they're statically compiled, it's their main selling point > If you're running code that you don't know who wrote, with no source code, that you can't patch, that nobody is taking responsibility for, then yeah you've got issues 25 million computers around the world still use Windows XP. It was launched 21 years ago, EOL 8 years ago. Very common actually, especially since most software in the world is not open source. People just keep using software that works.
- kelnos 4y ago
  > If you're running code that you don't know who wrote, with no source code, that you can't patch, that nobody is taking responsibility for, then yeah you've got issues. This is the default state of affairs for nearly everyone who uses a computer. We can either throw our hands up and futilely say "well they shouldn't do that!", or we can try to solve the problem.
preseinger 4y ago
> 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.

SomeCallMeTim 4y ago

The advantage of being able to build to a binary is that you can then distribute the binary directly instead of distributing source and forcing people to rebuild it. When 98% of your users only have the binary and not the source code it means 98% of your users won't even be aware that they need a new version that isn't vulnerable. Remember the vulnerability disclosure will be something like "Log4Go has a vulnerability!!", not that the binary apps you've downloaded have a vulnerability. So if it affects 200 projects, every one of those projects will also have to publish vulnerability notifications independently. And frankly 80% of those projects will likely be abandoned or at least neglected after a couple of years, leaving many people with vulnerable binaries they don't even know to check for vulnerabilities. In other words, they very advantage of Go (easy to distribute binaries directly!) is a security disadvantage. If you instead installed the app using a package manager, the package manager could at least notify you that you have a package with a security issue. But that's nothing new; security and ease-of-use are often at odds.