3 ms·

It’s probably easy to frame this as closed source versus open source, but honestly this can happen to anyone and I think we have numerous examples of Linux dist

It’s probably easy to frame this as closed source versus open source, but honestly this can happen to anyone and I think we have numerous examples of Linux distributions also having their core servers compromised leading to similar risks in distributing malicious software. That said I’d rather be running an operating system with reproducible builds based on open source software. I suspect problems like this would have been more quickly discovered, before hundreds and thousands of users were affected.

bshipp 8y ago
I also prefer the open source concept, but I always have--in the back of my mind--the case of Azer Koçulu: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ https://qz.com/646467/how-one-programmer-broke-the-internet-... I recognize that it's a leap to go from deleting a repository to converting it toward malicious intent (although sometimes it's likely not as big of a leap as we think), but as open source continues to build libraries on top of other libraries we do open ourselves to the risk that one of those innocuous libraries, at some point in the future, could end up causing issues. The other problem is that open source users often expect that the "crowd" will discover and identify issues fairly quickly because everyone is looking for them. But not everyone is looking for them. I can probably count on two hands the number of times I've gone through the source code of the libraries that I use, and I suspect most others are in a similar position. We all expect some bored soul in the world is doing the looking, but the truth is that they'll only start looking if something breaks.
- peterwwillis 8y ago
  I've noticed how obvious security problems get "discovered" over the years, when people already knew about them. What happens is, someone new finds the bug and makes a big stink about it being exploited. Everyone realizes the bug is a huge problem and then, one by one, every software project with that bug incorporates a fix or mediation. What should have never existed soon becomes another in a line of "standard fixes" that every system afterwards has to account for. There are things that (in retrospect) should be a standard part of all open source supply chains. Basic code vuln scanning, code signing+verifying, reproducible builds, redundant copies of code, and licenses permitting keeping code around to prevent breaking other code. But they're not standard - yet. So one by one, we have to run into these problems and break things before they're addressed and later become de-facto standards. I've noticed that this mirrors real life. In real life you can notice that an intersection is dangerous and needs a stop sign. But until a schoolbus full of children is plowed into, nobody lifts a finger. It's the same in technology. You can't just mention the big potential problem; you have to wait for the explosion. I spent months trying to get websites on the internet to mention that the default options they suggest for ssh-keygen are fundamentally insecure and dangerous, and while all of them acknowledge this is a fact, most of them won't update their guides. Not until someone creates a virus that finds and exposes vulnerable ssh key passwords around the world. Then all of a sudden whatever implicit bias they had against doing the work will disappear, as fear of impending consequences takes over.
  - toyg 8y ago
    > I've noticed that this mirrors real life. This is because taking additional or remedial actions is work. That work has to be justified against a hierarchy of needs. Until that justification is credible enough, work will be allocated elsewhere.
mattkevan 8y ago
It's certainly happened to open source projects. If I remember correctly both Handbrake and Transmission had their update mechanisms poisoned with malware.

bshipp 8y ago

I also prefer the open source concept, but I always have--in the back of my mind--the case of Azer Koçulu: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ https://qz.com/646467/how-one-programmer-broke-the-internet-... I recognize that it's a leap to go from deleting a repository to converting it toward malicious intent (although sometimes it's likely not as big of a leap as we think), but as open source continues to build libraries on top of other libraries we do open ourselves to the risk that one of those innocuous libraries, at some point in the future, could end up causing issues. The other problem is that open source users often expect that the "crowd" will discover and identify issues fairly quickly because everyone is looking for them. But not everyone is looking for them. I can probably count on two hands the number of times I've gone through the source code of the libraries that I use, and I suspect most others are in a similar position. We all expect some bored soul in the world is doing the looking, but the truth is that they'll only start looking if something breaks.

peterwwillis 8y ago
I've noticed how obvious security problems get "discovered" over the years, when people already knew about them. What happens is, someone new finds the bug and makes a big stink about it being exploited. Everyone realizes the bug is a huge problem and then, one by one, every software project with that bug incorporates a fix or mediation. What should have never existed soon becomes another in a line of "standard fixes" that every system afterwards has to account for. There are things that (in retrospect) should be a standard part of all open source supply chains. Basic code vuln scanning, code signing+verifying, reproducible builds, redundant copies of code, and licenses permitting keeping code around to prevent breaking other code. But they're not standard - yet. So one by one, we have to run into these problems and break things before they're addressed and later become de-facto standards. I've noticed that this mirrors real life. In real life you can notice that an intersection is dangerous and needs a stop sign. But until a schoolbus full of children is plowed into, nobody lifts a finger. It's the same in technology. You can't just mention the big potential problem; you have to wait for the explosion. I spent months trying to get websites on the internet to mention that the default options they suggest for ssh-keygen are fundamentally insecure and dangerous, and while all of them acknowledge this is a fact, most of them won't update their guides. Not until someone creates a virus that finds and exposes vulnerable ssh key passwords around the world. Then all of a sudden whatever implicit bias they had against doing the work will disappear, as fear of impending consequences takes over.
- toyg 8y ago
  > I've noticed that this mirrors real life. This is because taking additional or remedial actions is work. That work has to be justified against a hierarchy of needs. Until that justification is credible enough, work will be allocated elsewhere.

mattkevan 8y ago

It's certainly happened to open source projects. If I remember correctly both Handbrake and Transmission had their update mechanisms poisoned with malware.