3 ms·

I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing. Instead, by pushing an intentionally br

I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing. Instead, by pushing an intentionally broken patch, It is foreseeable that there will be hundreds or thousands of maintainers of other code that will have to respond to your actions. I think it’s reasonable to call that an attack.

toomuchtodo 5y ago
If you consume open source code without reviewing it, it’s no different than executing arbitrary user code. Your environment’s security is based on hope and trust. Maintainers shouldn’t be malicious, absolutely, but users should do a bit more than pulling code and running it. Otherwise, it’s curl | bash dressed up with a ci pipeline. How many times does dependabot bump your dependency revisions and no one looks except to ensure tests pass?
- bergheim 5y ago
  Doing this for something like GNU/Linux is simply not practical, _at all_. In what world can a user be expected to do little else that simply install linux? Since you pipe, can I assume you know everything about the kernel tree? And bad actors work in companies as well. At some point you just have to trust what you are using.
  - toomuchtodo 5y ago
    I agree we’ve built a metropolis on sand, and a large component of solving for this problem is going to be some form of trust and managing that trust (more code reviews with an audit trail of some sort, human gating of code changes using automated risk modeling, etc).
  - caymanjim 5y ago
    People install Linux by picking a distribution to install. The maintainers of the distributions look at the packages they're including. For example, this broken colors package will never end up in any of them, because there are gatekeepers. It's certainly impractical for every developer to vet every package they use, so much so that almost no developers vet any of the packages they use. What's needed are more gatekeepers. Repos like NPM would be well-served by coming up with mechanisms to support this. Off the top of my head, some sort of "this is safe" consensus, whereby the community can vouch for specific immutable versions of packages, that don't become the default version until they cross a threshhold. Organizations with a history of good stewardship and trusted validation processes could be allowed to skip the vetting step (e.g. things published by groups like the Apache Foundation or even corporations like Microsoft). I'm not arguing that one-man shops shouldn't be able to publish to NPM, just that there should be something like a "--untrusted" flag that's required before unverified updates are installed. And I'm not calling out NPM; every package repo has this problem.
- encoderer 5y ago
  A lot of it is based on trust, that’s evidently true, and as such, I think it’s perfectly fine to publicly shame a maintainer who looks to have breached that trust.
fivea 5y ago
>>I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing. This sounds like a gross misrepresentation of what happened. It has been reported that the author of the colors and faker packages announced last year that he was no longer willing to do free work for Fortune500 companies. He also proceeded to state quite publicly that either companies paid him for his work, or they should fork the project and maintain it themselves instead of taking advantage of everyone else's work. After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel. https://web.archive.org/web/20210704022108/https://github.com/Marak/faker.js/issues/1046 https://web.archive.org/web/20210704022108/https://github.co... Source: https://www.theverge.com/2022/1/9/22874949/developer-corrupts-open-source-libraries-projects-affected https://www.theverge.com/2022/1/9/22874949/developer-corrupt... These packages are his circus, and his clowns run the act he chooses. If anything, this update showcases the completely abhorrent security culture in place in these mega-companies, which literally ingest into their product line anything that they can find on GitHub without a shred of due diligence.
- acdha 5y ago
  > After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel. Artistic would be a new color scheme or maybe a “support open source maintainers” message. The accurate description you didn't give is sabotage because he introduced an infinite loop: https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d13d28632bd8a049ff136fb6#diff-92bbac9a308cd5fcf9db165841f2d90ce981baddcb2b1e26cfff170929af3bd1R18 https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...
  - jamesfinlayson 5y ago
    Not to mention plenty of people (me at a big company included) used both of these packages as indirectly (as dependencies of dependencies) and had no idea about this until this week.
  - fivea 5y ago
    > Artistic would be a new color scheme or maybe a “support open source maintainers” message. The author already did that, and complained about fortune500 companies mooching their work without giving anything in return. The author stated that people should fork the repo if they intended to keep using it. The author made said statements a year ago. Is a year enough time to take action? Now the author decided to do a major version release with a protest version of his own work, and that makes him a villain?

toomuchtodo 5y ago

If you consume open source code without reviewing it, it’s no different than executing arbitrary user code. Your environment’s security is based on hope and trust. Maintainers shouldn’t be malicious, absolutely, but users should do a bit more than pulling code and running it. Otherwise, it’s curl | bash dressed up with a ci pipeline. How many times does dependabot bump your dependency revisions and no one looks except to ensure tests pass?

bergheim 5y ago
Doing this for something like GNU/Linux is simply not practical, _at all_. In what world can a user be expected to do little else that simply install linux? Since you pipe, can I assume you know everything about the kernel tree? And bad actors work in companies as well. At some point you just have to trust what you are using.
- toomuchtodo 5y ago
  I agree we’ve built a metropolis on sand, and a large component of solving for this problem is going to be some form of trust and managing that trust (more code reviews with an audit trail of some sort, human gating of code changes using automated risk modeling, etc).
- caymanjim 5y ago
  People install Linux by picking a distribution to install. The maintainers of the distributions look at the packages they're including. For example, this broken colors package will never end up in any of them, because there are gatekeepers. It's certainly impractical for every developer to vet every package they use, so much so that almost no developers vet any of the packages they use. What's needed are more gatekeepers. Repos like NPM would be well-served by coming up with mechanisms to support this. Off the top of my head, some sort of "this is safe" consensus, whereby the community can vouch for specific immutable versions of packages, that don't become the default version until they cross a threshhold. Organizations with a history of good stewardship and trusted validation processes could be allowed to skip the vetting step (e.g. things published by groups like the Apache Foundation or even corporations like Microsoft). I'm not arguing that one-man shops shouldn't be able to publish to NPM, just that there should be something like a "--untrusted" flag that's required before unverified updates are installed. And I'm not calling out NPM; every package repo has this problem.
encoderer 5y ago
A lot of it is based on trust, that’s evidently true, and as such, I think it’s perfectly fine to publicly shame a maintainer who looks to have breached that trust.

fivea 5y ago

>>I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing. This sounds like a gross misrepresentation of what happened. It has been reported that the author of the colors and faker packages announced last year that he was no longer willing to do free work for Fortune500 companies. He also proceeded to state quite publicly that either companies paid him for his work, or they should fork the project and maintain it themselves instead of taking advantage of everyone else's work. After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel. https://web.archive.org/web/20210704022108/https://github.com/Marak/faker.js/issues/1046 https://web.archive.org/web/20210704022108/https://github.co... Source: https://www.theverge.com/2022/1/9/22874949/developer-corrupts-open-source-libraries-projects-affected https://www.theverge.com/2022/1/9/22874949/developer-corrupt... These packages are his circus, and his clowns run the act he chooses. If anything, this update showcases the completely abhorrent security culture in place in these mega-companies, which literally ingest into their product line anything that they can find on GitHub without a shred of due diligence.

acdha 5y ago
> After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel. Artistic would be a new color scheme or maybe a “support open source maintainers” message. The accurate description you didn't give is sabotage because he introduced an infinite loop: https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d13d28632bd8a049ff136fb6#diff-92bbac9a308cd5fcf9db165841f2d90ce981baddcb2b1e26cfff170929af3bd1R18 https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...
- jamesfinlayson 5y ago
  Not to mention plenty of people (me at a big company included) used both of these packages as indirectly (as dependencies of dependencies) and had no idea about this until this week.
- fivea 5y ago
  > Artistic would be a new color scheme or maybe a “support open source maintainers” message. The author already did that, and complained about fortune500 companies mooching their work without giving anything in return. The author stated that people should fork the repo if they intended to keep using it. The author made said statements a year ago. Is a year enough time to take action? Now the author decided to do a major version release with a protest version of his own work, and that makes him a villain?