6 ms·

Kind of sad that people are more angry at Dominic than the malicious updater. Seems there is a bit of a "boys will be boys" phenomenon going on.

• TAForObvReasons 8y ago
  To an extent it's because his name is in the repo name (dominictarr/event-stream) https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-stream so he is an easy and obvious scapegoat. But it seems people in general forgot that they are not paying and are not entitled to any sort of support.
  • nailer 8y ago
    People in this case aren't asking for support, they're asking for the project to have been given to a trusted maintainer or declared abandoned.
    • mehrdadn 8y ago
      To be honest I wouldn't expect an abandoned project to be any different. I would expect it to have lost its maintainer, not switched from a trustworthy maintainer to a malicious one. Edit: Clarified second sentence.
      • madrox 8y ago
        No maintainer is malicious...until they are. Be honest with yourself: how many dependencies have you vetted the maintainer before including? If n > 0 then you're just as susceptible.
        • mifreewil 8y ago
          I wouldn't just add some random maintainer with a new GitHub account to a project I controlled. If they had made some contributions via pull requests, I would consider it or if they were a maintainer of other projects with actual users. In this case, there was no vetting at all. A brand new GitHub account with a couple forks. I'm not placing all the blame on the original maintainer as I understand his philosophy of handing off the torch, but I think it's a naive thing to do, as this has shown. Ultimately, this has been a good demonstration of a weakness with the ecosystem and I think there are a lot of things that could be improved here to help mitigate this in the future.
    • sytelus 8y ago
      How do you suggest finding trusted maintainer who would not turn malicious at later date?
      • nailer 8y ago
        I don’t. No guarantees of anything. But we can probably do better than random Chinese dude with no other projects or contribs
• mehrdadn 8y ago
  I think people are just drawing a distinction between fault and responsibility. Neither is a subset of the other.
  • madrox 8y ago
    This, I think, is a sucker's argument. Responsibility is not putting trust in a dependency they themselves have no control over. Responsibility is not letting yourself get into an obviously bad situation. It's not even the first time this has happened to NPM. Remember left pad? No, this thread didn't happen because a bunch of developed chose to make this a conversation about responsibility more than fault. They're mad they got suckered and Dominic is the best scapegoat.
    • mehrdadn 8y ago
      > This, I think, is a sucker's argument. Responsibility is not putting trust in a dependency they themselves have no control over. Responsibility can fall on multiple people. I don't understand why everyone looks at things in such a binary way. Responsibility, fault, etc. are not binary things. Two or more people responsible for one problem can be both upset at each other perfectly justifiably.
      • randallsquared 8y ago
        Responsibility is a hard problem. It's quite true that more than one person can be responsible for something, in part, but there's only so much responsibility to go around: whatever damage irresponsibility causes, more than one person cannot be responsible for the full damage, if we're going to maintain any consistency.
        • marcus_holmes 8y ago
          Authority and Responsibility go hand-in-hand. If you have authority over something/someone, then you are responsible for it/them. You cannot be responsible for something you have no authority over, and you should not have authority for something you have no responsibility for. In this case, every developer has authority over their own code base. If I decide to include some random code from the internet in my project then I am responsible for that decision. If whoever has commit privileges on that random code decides to commit malicious code, then they have responsibility for that. However, that doesn't make them responsible for my project, because they have no authority over my project. Including a dependency in a project is a security vulnerability. It may be worth the risk, it may not, but it is definitely a risk. And responsibility for taking that risk is entirely on the person who took the decision to include that dependency.