3 ms·

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-i

by 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.

by bshipp 8y ago

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.