6 ms·

People didn't actively go seek out a new version. He intentionally abused semver to disguise it as a safe update, when it was not. I know it's popular in prog

People didn't actively go seek out a new version. He intentionally abused semver to disguise it as a safe update, when it was not. I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement.

shepherdjerred 5y ago
It's his project. It's a free, open-source project. What does the maintainer owe us? Absolutely nothing. > I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement. Be thankful that all he did was spam the console. It could have been something more malicious. Updating dependencies without auditing source code is a very common practice, but that doesn't mean it's not the victim's fault. It is unrealistic to audit the insane amount of source that our projects are built on, but that is the exact tradeoff that we're making in exchange for the productivity of not building libraries ourselves or paying for those libraries. Open source is something that we're gifted not something that we're owed. If you disagree, then feel free to either use exclusively proprietary software where you can have expectations of the maintainer, or build all of the functionality that you need by yourself.
- sakarisson 5y ago
  > Be thankful that all he did was spam the console. Why would I be thankful for that? If you slap me, should I be thankful that my nose wasn't broken?
  - baq 5y ago
    Fool me once… etc.
  - jzb 5y ago
    If nothing else, he illustrated a point that many people needed made. They got off cheap - he didn't exfiltrate data, install malware or whatever. He showed that their supply chain is insecure, and that they are trusting way too much in the kindness of unpaid strangers. If your business or development practices depend on pulling a bunch of packages from NPM or other sources un-audited and so forth - especially straight into production! - you need to seriously rethink things. You got off relatively light, this time, if you were impacted by this.
- afiori 5y ago
  I think that open source developers still owe us not to maliciously run malware on our machines. To be clear they do not owe us to produce good code, or to keep producing code, or to produce the code we want; it is remarkably close to charity giving: the developer/mantainer is donating their work/code to the community. Just like charity you should not give poisoned gifts. The kid that gave homeless people oreos with toothpaste filling wasn't charitably offering food to someone in need, he was maliciously offering them a "poisoned" gift.
  - rakoo 5y ago
    Open source developers don't owe anyone anything. It's this entitlement that has led so many of our fellow people in the community all the way to depression. Stop expecting something when it was explicitly stated that software is provided with no guarantees.
    - afiori 5y ago
      My point is different: People owe everyone not to maliciously inject malware on their machine, it is irrelevant whether you are an open source developer or not. The author published the packages to a public registry with the expectation that the code would be run by others, it was not just a random github project, it literally invited others to run the code by being registered on npm. The author explicitely offered no warranty on the code, but distributing malware is both illegal and against npm ToS. Being an open source developer does not put you above ethics. The only thing that would change this would be if some third party was mirroring their code on npm without the author consent.
      - oauea 5y ago
        If you choose to download my code and include it in your project and it doesn't do what you expect, that is on you. The colors library has an infinite loop and you shipped that version to your end users? That's on you. Test and pin your dependencies. Not doing so is the true offense. Be upset with AWS and the likes who will run unvetted third party code on your machine. Also note that an infinite loop is not malware. Implying such is insane. Are you now going to call every piece of crashing software malware?
alex_sf 5y ago
> People didn't actively go seek out a new version. When they set their dependency versions to 'latest', that's exactly what they are doing.
- fault1 5y ago
  however, I think the more common case is that they set it to the latest bounded by a minor or patch version (as opposed to a major version) as defined by semvar. at least that seems to be quite common in the npm/js world.
rakoo 5y ago
> People didn't actively go seek out a new version. Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version. You can't use tools you don't understand and blame someone else if it doesn't work as you expect it to.
- PragmaticPulp 5y ago
  > Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version. No, it pulls the specified version. The affected packages fixed it by removing the leading carpet in the version specifier, which was designed to allow patch version bumps for things like security fixes. He literally abused the versioning system designed to allow security fixes by introducing a breakage and disguising it as a non-breaking change.
oauea 5y ago
> People didn't actively go seek out a new version. They did. They chose not to pin their dependency versions, so this is their clear explicit choice. They also chose not to test their dependency updates before pushing it through to their end users, pure negligence by e.g. AWS who was affected by this.

shepherdjerred 5y ago

It's his project. It's a free, open-source project. What does the maintainer owe us? Absolutely nothing. > I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement. Be thankful that all he did was spam the console. It could have been something more malicious. Updating dependencies without auditing source code is a very common practice, but that doesn't mean it's not the victim's fault. It is unrealistic to audit the insane amount of source that our projects are built on, but that is the exact tradeoff that we're making in exchange for the productivity of not building libraries ourselves or paying for those libraries. Open source is something that we're gifted not something that we're owed. If you disagree, then feel free to either use exclusively proprietary software where you can have expectations of the maintainer, or build all of the functionality that you need by yourself.

sakarisson 5y ago
> Be thankful that all he did was spam the console. Why would I be thankful for that? If you slap me, should I be thankful that my nose wasn't broken?
- baq 5y ago
  Fool me once… etc.
- jzb 5y ago
  If nothing else, he illustrated a point that many people needed made. They got off cheap - he didn't exfiltrate data, install malware or whatever. He showed that their supply chain is insecure, and that they are trusting way too much in the kindness of unpaid strangers. If your business or development practices depend on pulling a bunch of packages from NPM or other sources un-audited and so forth - especially straight into production! - you need to seriously rethink things. You got off relatively light, this time, if you were impacted by this.
afiori 5y ago
I think that open source developers still owe us not to maliciously run malware on our machines. To be clear they do not owe us to produce good code, or to keep producing code, or to produce the code we want; it is remarkably close to charity giving: the developer/mantainer is donating their work/code to the community. Just like charity you should not give poisoned gifts. The kid that gave homeless people oreos with toothpaste filling wasn't charitably offering food to someone in need, he was maliciously offering them a "poisoned" gift.
- rakoo 5y ago
  Open source developers don't owe anyone anything. It's this entitlement that has led so many of our fellow people in the community all the way to depression. Stop expecting something when it was explicitly stated that software is provided with no guarantees.
  - afiori 5y ago
    My point is different: People owe everyone not to maliciously inject malware on their machine, it is irrelevant whether you are an open source developer or not. The author published the packages to a public registry with the expectation that the code would be run by others, it was not just a random github project, it literally invited others to run the code by being registered on npm. The author explicitely offered no warranty on the code, but distributing malware is both illegal and against npm ToS. Being an open source developer does not put you above ethics. The only thing that would change this would be if some third party was mirroring their code on npm without the author consent.
    - oauea 5y ago
      If you choose to download my code and include it in your project and it doesn't do what you expect, that is on you. The colors library has an infinite loop and you shipped that version to your end users? That's on you. Test and pin your dependencies. Not doing so is the true offense. Be upset with AWS and the likes who will run unvetted third party code on your machine. Also note that an infinite loop is not malware. Implying such is insane. Are you now going to call every piece of crashing software malware?

alex_sf 5y ago

> People didn't actively go seek out a new version. When they set their dependency versions to 'latest', that's exactly what they are doing.

fault1 5y ago
however, I think the more common case is that they set it to the latest bounded by a minor or patch version (as opposed to a major version) as defined by semvar. at least that seems to be quite common in the npm/js world.

rakoo 5y ago

> People didn't actively go seek out a new version. Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version. You can't use tools you don't understand and blame someone else if it doesn't work as you expect it to.

PragmaticPulp 5y ago
> Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version. No, it pulls the specified version. The affected packages fixed it by removing the leading carpet in the version specifier, which was designed to allow patch version bumps for things like security fixes. He literally abused the versioning system designed to allow security fixes by introducing a breakage and disguising it as a non-breaking change.

oauea 5y ago

> People didn't actively go seek out a new version. They did. They chose not to pin their dependency versions, so this is their clear explicit choice. They also chose not to test their dependency updates before pushing it through to their end users, pure negligence by e.g. AWS who was affected by this.