8 ms·

Attack is hyperbole. This wasn't an attack. Nothing was attacked. This verbiage has got to stop being used around this. A maintainer of popular packages got fed

Attack is hyperbole. This wasn't an attack. Nothing was attacked. This verbiage has got to stop being used around this. A maintainer of popular packages got fed up with being a maintainer - rightly or wrongly - and decided that they were going to alter their code - publicy no less (a far more dubious move would have been to make these changes in private and release that to npm, without pushing it to github also, in my mind) - and that means this code was working as intended by the project / package maintainer. It was not injecting harmful code onto the machine, it was not an "attack" on anything, in any real sense. I feel all the media is doing so far is raking the maintainer over a fire, instead of asking the question of how did we get here in the first place? Why would a maintainer feel they need to take actions like this? What are they trying to achieve? Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer. I know it inconveniences everyone, sure, and would I have done this if they were my packages? No, I'd go through a normal deprecation process of announcing its deprecation, archiving the repository, and plainly stating that the package is no longer maintained. With that said, consumers can always choose a different library. This wasn't malicious, or an attack. It was an update to the package working as the maintainer of the project intended. If lodash issued a breaking change, would that be considered an "attack"? They even followed semver, by bumping the packages to their next major version. I think this event also served to expose how little organizations have around testing for breaking changes in their dependencies, which may be adding fuel to the issue. EDIT: this is a plea for more nuance in the conversation. I think there has been an unreasonable amount of haste in passing judgement in this situation, that, after doing even just a little bit of background research, seems to suggest there is more moving parts than meets the surface.

encoderer 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. 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.
jamincan 5y ago
In what world is it not malicious? He owned the packages and I guess that gives him the right to do what he likes with it, but I have a hard time believing he didn't do it deliberately fully aware that a whole bunch of people would update and it would cause disruption. It's not an exploit, but it's certainly malicious, and I don't think it's unreasonable to call it an attack.
- no_wizard 5y ago
  Sure did, however, does that mean its malicious? The definition of malicious, according to Merriam Webster[0], is the following >having or showing a desire to cause harm to someone : given to, marked by, or arising from malice Was the intention here to cause someone harm? What the intention here malice? Which conversely has this definition[1] >desire to cause pain, injury, or distress to another Was this their primary motivation? What evidence do we have that is in fact an action driven by malice? In fact, I don't see any, especially after doing roughly 20 minutes of research, I have arrived at the following: Reading the public history surrounding the maintainer of these projects, the issue trackers of the repositories, and the maintainers own blog, you may come from a different conclusion entirely. If I was to speculate - and mind you, I am speculating, as I don't know the maintainer personally nor do I claim to understand them completely - there is a clear sense of mental strain they are feeling from the burdens here. Being burnt out, feeling taken advantage of, can lead to very real and deep feels of depression and/or other mental challenges (this I speak first hand to), for starters. I think the maintainer - again, speculating here, however evidence does seem to suggest this - is acting from a place of disillusionment, and possibly is resentful of their status in the word, relative to those benefiting from their contributions to open source software. Are they right to feel this way? Maybe, maybe not. However, is this malice? That's the question. Is this actually malicious? All evidence points to no, its not an act of malice. Its an act of someone who is disillusioned, strained, and struggling. I think the most reasonable interpretation given all the evidence is that they are trying to raise some kind of awareness - albeit in ways that I don't think is well communicated, due to the issues I previously highlighted - most likely. I could be wrong, I'm just following the publicly available evidence and, its a lot more murky than this is an malicious act by a malicious maintainer acting in malice. And again, this brings up the broader issue around open source maintainability, longevity, the role of consumer and maintainer, and how to build better symbiotic relationships around that, yet we aren't talking about what lead to this event, which I would argue is more important than what happened. My ask is for nuance in this conversation, where there is seemingly little. [0]: https://www.merriam-webster.com/dictionary/malicious https://www.merriam-webster.com/dictionary/malicious [1]: https://www.merriam-webster.com/dictionary/malice https://www.merriam-webster.com/dictionary/malice
blitz_skull 5y ago
What he did was actively malicious. There was ill-will behind the actions. He did it for the purpose of interrupting a lot of stuff that was working, simply to make some sort of statement. It was an attack, by ALMOST any definition. The fact that it was a very benign attack with very few real consequences, doesn't make it less of what it was—an attack.
- keneda7 5y ago
  He did not force anyone to update the package. They did that without looking at it. He no longer wanted his work to be disturbed. You may not agree with how he did it but calling it an attack is completely ridiculous. These comments on HN are sending a pretty clear message out... don't open source anything. It is really really unfortunate.
  - chaostheory 5y ago
    No one expects a maintainer to purposely break their project. If he wanted to end it, he should have just sent a goodbye message signaling the end of his involvement with maintenance. This has been done many times before without incident. If he wanted to be paid, he should have either picked the appropriate license for his software from the start, or just changed it for future versions. The latter has also been done before with SugarCRM being one example To be fair, Marak seems to be mentally unwell right now, which helps explain but doesn't condone his behavior https://abc7ny.com/suspicious-package-queens-astoria-fire/6425363 https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
    - heavyset_go 5y ago
      > No one expects a maintainer to purposely break their project. If you're using a 3rd party dependency, especially one you aren't paying for, you should expect it to break or disappear at any time.
      - chaostheory 5y ago
        Falling into disrepair, or not being maintained due to various valid reasons: yes. This happens all the time. Some asshole maliciously breaking your stuff: no. I do not use either colorsjs or fakerjs. I was close since I used the Ruby version of faker that Marak ported into nodejs as fakerjs.
deleted 5y ago
[deleted]
gitgrump 5y ago
Dear Christ, I'm sick of this dichotomy. Deliberately releasing code like this is malicious, and was clearly done with intent. I'm not sure if you could sue, but there is such a thing as torts. You can't booby trap your yard and then be like "BUT I SAID NO WARRANTY!" when someone expects it to be a normal yard and then blows their leg off. > If Lodash issued a breaking change... It's called intent. Did Lodash _intend_ to break users' programs? Probably not. That's for a court to decide. Did this dude intend to break users' programs? The legal system is set up to resolve questions like this, not get fooled by clever gotchas from software developers. Intent matters in the eyes of the law and I'm utterly flummoxed and quite frankly concerned that so many developers don't understand that. Simultaneously, pulling thousands of double digit layers deep of random-ass dynamic code dependencies is _also_ a bad idea at best, and professional negligence at worst. The package author can be liable. The people who rely on him can, at the same time, make bad professional choices. Both things can be true.
- runarberg 5y ago
  You are raising point which noone is disputing. Yes stuff broke, people’s time was wasted, this was the intention. However that does not necessitate malice. IWW for example calls these kinds of sabotage a direct action. The malice is towards the oppressors. The goal is to slow down production and such that our oppressors suffer. This act is really no different then a strike. A striking worker is only malicious towards those who unfavorably profits from their labor. Other workers might suffer, but a true worker will stand in solidarity, for direct action is an act of love for the entire working class.
  - gitgrump 5y ago
    - runarberg 5y ago
  - sintaxi 5y ago
    Keep in mind Marak was active in the issue tracker afterwards pretending to be fixing the "bug". Marak didn't change the description, readme, or roadmap of the package. He passed the release off as a functioning library that deliberately crashes any process that used the library. That is a Trojan.
wruza 5y ago
With that said, consumers can always choose a different library. Yeah, you can always just choose a different css-loader > cssnano > svgo > colors depchain, because there's plenty. Dependencies like that empower people great, and we all know what comes with it. When you're in a hot summer bus, it's immoral to turn off the AC only because it was you who decorated the knob.
heavyset_go 5y ago
> It was not injecting harmful code onto the machine, it was not an "attack" on anything, in any real sense. I feel all the media is doing so far is raking the maintainer over a fire, instead of asking the question of how did we get here in the first place? Why would a maintainer feel they need to take actions like this? What are they trying to achieve? > Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer. I agree with all of your points. I would be more sympathetic to the backlash if those affected were paying license holders, but that's not what happened. It is a privilege to use someone's hobby project that you didn't write for free and with no strings attached.
- krapp 5y ago
  >It is a privilege to use someone's hobby project that you didn't write for free and with no strings attached. It isn't a privilege, as far as FOSS is concerned, it's a fundamental right. Whether one pays or not is irrelevant, that code was given to the community and it belongs to the community. No one, not even the author or project maintainer, has the right to vandalize community property regardless of their motives.
  - heavyset_go 5y ago
    FOSS doesn't mean code is in the public domain, nor does it mean that the code is held in a public trust. It is very much the property of copyright holder. If the community feels this way, then they could have done the work to develop, maintain and distribute the product themselves. They didn't do that, though. They chose to depend on the labor of someone who was not compensated for their time or work, which is a privilege. No one is entitled to the developer's time or labor.
    - fault1 5y ago
      But let's not pretend the original maintainer did all of the work or owned all of the copyright. There were a ton of contributors to color, and some dude actually had more lines of code edited than the original maintainer: https://github.com/Marak/colors.js/commits/master https://github.com/Marak/colors.js/commits/master and faker.js seems to be more or less a port of a ruby library which was a port of a perl library.
9935c101ab17a66 5y ago
It's interesting that you strongly defend Marak here, and were also the one who shared his blog post ~seven months ago about how retool had stolen his code and his idea (which decidedly wasn't the case).

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

jamincan 5y ago

In what world is it not malicious? He owned the packages and I guess that gives him the right to do what he likes with it, but I have a hard time believing he didn't do it deliberately fully aware that a whole bunch of people would update and it would cause disruption. It's not an exploit, but it's certainly malicious, and I don't think it's unreasonable to call it an attack.

no_wizard 5y ago
Sure did, however, does that mean its malicious? The definition of malicious, according to Merriam Webster[0], is the following >having or showing a desire to cause harm to someone : given to, marked by, or arising from malice Was the intention here to cause someone harm? What the intention here malice? Which conversely has this definition[1] >desire to cause pain, injury, or distress to another Was this their primary motivation? What evidence do we have that is in fact an action driven by malice? In fact, I don't see any, especially after doing roughly 20 minutes of research, I have arrived at the following: Reading the public history surrounding the maintainer of these projects, the issue trackers of the repositories, and the maintainers own blog, you may come from a different conclusion entirely. If I was to speculate - and mind you, I am speculating, as I don't know the maintainer personally nor do I claim to understand them completely - there is a clear sense of mental strain they are feeling from the burdens here. Being burnt out, feeling taken advantage of, can lead to very real and deep feels of depression and/or other mental challenges (this I speak first hand to), for starters. I think the maintainer - again, speculating here, however evidence does seem to suggest this - is acting from a place of disillusionment, and possibly is resentful of their status in the word, relative to those benefiting from their contributions to open source software. Are they right to feel this way? Maybe, maybe not. However, is this malice? That's the question. Is this actually malicious? All evidence points to no, its not an act of malice. Its an act of someone who is disillusioned, strained, and struggling. I think the most reasonable interpretation given all the evidence is that they are trying to raise some kind of awareness - albeit in ways that I don't think is well communicated, due to the issues I previously highlighted - most likely. I could be wrong, I'm just following the publicly available evidence and, its a lot more murky than this is an malicious act by a malicious maintainer acting in malice. And again, this brings up the broader issue around open source maintainability, longevity, the role of consumer and maintainer, and how to build better symbiotic relationships around that, yet we aren't talking about what lead to this event, which I would argue is more important than what happened. My ask is for nuance in this conversation, where there is seemingly little. [0]: https://www.merriam-webster.com/dictionary/malicious https://www.merriam-webster.com/dictionary/malicious [1]: https://www.merriam-webster.com/dictionary/malice https://www.merriam-webster.com/dictionary/malice

blitz_skull 5y ago

What he did was actively malicious. There was ill-will behind the actions. He did it for the purpose of interrupting a lot of stuff that was working, simply to make some sort of statement. It was an attack, by ALMOST any definition. The fact that it was a very benign attack with very few real consequences, doesn't make it less of what it was—an attack.

keneda7 5y ago
He did not force anyone to update the package. They did that without looking at it. He no longer wanted his work to be disturbed. You may not agree with how he did it but calling it an attack is completely ridiculous. These comments on HN are sending a pretty clear message out... don't open source anything. It is really really unfortunate.
- chaostheory 5y ago
  No one expects a maintainer to purposely break their project. If he wanted to end it, he should have just sent a goodbye message signaling the end of his involvement with maintenance. This has been done many times before without incident. If he wanted to be paid, he should have either picked the appropriate license for his software from the start, or just changed it for future versions. The latter has also been done before with SugarCRM being one example To be fair, Marak seems to be mentally unwell right now, which helps explain but doesn't condone his behavior https://abc7ny.com/suspicious-package-queens-astoria-fire/6425363 https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
  - heavyset_go 5y ago
    > No one expects a maintainer to purposely break their project. If you're using a 3rd party dependency, especially one you aren't paying for, you should expect it to break or disappear at any time.
    - chaostheory 5y ago
      Falling into disrepair, or not being maintained due to various valid reasons: yes. This happens all the time. Some asshole maliciously breaking your stuff: no. I do not use either colorsjs or fakerjs. I was close since I used the Ruby version of faker that Marak ported into nodejs as fakerjs.

deleted 5y ago

[deleted]

gitgrump 5y ago

Dear Christ, I'm sick of this dichotomy. Deliberately releasing code like this is malicious, and was clearly done with intent. I'm not sure if you could sue, but there is such a thing as torts. You can't booby trap your yard and then be like "BUT I SAID NO WARRANTY!" when someone expects it to be a normal yard and then blows their leg off. > If Lodash issued a breaking change... It's called intent. Did Lodash _intend_ to break users' programs? Probably not. That's for a court to decide. Did this dude intend to break users' programs? The legal system is set up to resolve questions like this, not get fooled by clever gotchas from software developers. Intent matters in the eyes of the law and I'm utterly flummoxed and quite frankly concerned that so many developers don't understand that. Simultaneously, pulling thousands of double digit layers deep of random-ass dynamic code dependencies is _also_ a bad idea at best, and professional negligence at worst. The package author can be liable. The people who rely on him can, at the same time, make bad professional choices. Both things can be true.

runarberg 5y ago
You are raising point which noone is disputing. Yes stuff broke, people’s time was wasted, this was the intention. However that does not necessitate malice. IWW for example calls these kinds of sabotage a direct action. The malice is towards the oppressors. The goal is to slow down production and such that our oppressors suffer. This act is really no different then a strike. A striking worker is only malicious towards those who unfavorably profits from their labor. Other workers might suffer, but a true worker will stand in solidarity, for direct action is an act of love for the entire working class.
- gitgrump 5y ago
  - runarberg 5y ago
- sintaxi 5y ago
  Keep in mind Marak was active in the issue tracker afterwards pretending to be fixing the "bug". Marak didn't change the description, readme, or roadmap of the package. He passed the release off as a functioning library that deliberately crashes any process that used the library. That is a Trojan.

wruza 5y ago

With that said, consumers can always choose a different library. Yeah, you can always just choose a different css-loader > cssnano > svgo > colors depchain, because there's plenty. Dependencies like that empower people great, and we all know what comes with it. When you're in a hot summer bus, it's immoral to turn off the AC only because it was you who decorated the knob.

heavyset_go 5y ago

> It was not injecting harmful code onto the machine, it was not an "attack" on anything, in any real sense. I feel all the media is doing so far is raking the maintainer over a fire, instead of asking the question of how did we get here in the first place? Why would a maintainer feel they need to take actions like this? What are they trying to achieve? > Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer. I agree with all of your points. I would be more sympathetic to the backlash if those affected were paying license holders, but that's not what happened. It is a privilege to use someone's hobby project that you didn't write for free and with no strings attached.

krapp 5y ago
>It is a privilege to use someone's hobby project that you didn't write for free and with no strings attached. It isn't a privilege, as far as FOSS is concerned, it's a fundamental right. Whether one pays or not is irrelevant, that code was given to the community and it belongs to the community. No one, not even the author or project maintainer, has the right to vandalize community property regardless of their motives.
- heavyset_go 5y ago
  FOSS doesn't mean code is in the public domain, nor does it mean that the code is held in a public trust. It is very much the property of copyright holder. If the community feels this way, then they could have done the work to develop, maintain and distribute the product themselves. They didn't do that, though. They chose to depend on the labor of someone who was not compensated for their time or work, which is a privilege. No one is entitled to the developer's time or labor.
  - fault1 5y ago
    But let's not pretend the original maintainer did all of the work or owned all of the copyright. There were a ton of contributors to color, and some dude actually had more lines of code edited than the original maintainer: https://github.com/Marak/colors.js/commits/master https://github.com/Marak/colors.js/commits/master and faker.js seems to be more or less a port of a ruby library which was a port of a perl library.

9935c101ab17a66 5y ago

It's interesting that you strongly defend Marak here, and were also the one who shared his blog post ~seven months ago about how retool had stolen his code and his idea (which decidedly wasn't the case).