9 ms·

If it's not fun anymore, you get nothing from maintaining a popular package

317 points by jashkenas 8y ago

drwl 8y ago
This references https://news.ycombinator.com/item?id=18534392 https://news.ycombinator.com/item?id=18534392 It looks like it's title has been changed from when I first read it.
- jashkenas 8y ago
  Yep. I submitted it with "Dominic Tarr’s Statement on the hacker hijacking of the event-stream NPM module", which was as descriptive of a title as I could think of quickly. It looks like the moderators have dinged the submission and changed it to: "If it's not fun anymore, you get nothing from maintaining a popular package" ... which I think we can all agree is generic, and fails to make the connection to the big news of the day. It may just be whispering into the wind, but if the mods are listening — how about "Dominic Tarr: statement on event-stream compromise", which uses the Gist's description, and helps folks know what this link is all about?
gwicks56 8y ago
Personally I felt people on GitHub were being way too harsh. He built something, moved on, and gave it away. He had no way of knowing the person who took it over would use it maliciously. Seriously, some of the comments blew my mind. Because he built it, he had a responsibility to maintain it forever, and was responsible for everything that happened with that code forever? Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. If you are using somebody else's code, is it their responsibility to look after it years after they have moved on, or your responsibility to make sure it's not full of bugs or malicious code.
- madrox 8y ago
  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.
- tathougies 8y ago
  The entitlement mentality of some people is insane.
  - tonyedgecombe 8y ago
    Especially when they aren't paying.
- vernie 8y ago
  Sayre's law, baby.
  - QuantumGood 8y ago
    Intensity of feeling is inversely proportional to issue value sometimes. Recent US political discourse seems to violate Sayre's law.
- bendmorris 8y ago
  >He had no way of knowing the person who took it over would use it maliciously. Then it was, clearly, negligent of him to give it to this person. He gave a stranger the power to do things in his name. He doesn't have to maintain the project forever - it seems like a much easier solution is: don't give away a project with your name on it to someone you don't know. Instead, encourage them to fork and release a new version under their own name. This is a surefire way to never have an exploit spread to thousands of people with your name on it.
  - runarberg 8y ago
    As a user of free software you should always accept the risk that it is maintained by a malicious actor. It is just as likely that the original author will turn malicious. You as a user have the responsibility of auditing all the free software you use.
    - bendmorris 8y ago
      People keep casually making this suggestion. In JS this can involve hundreds or thousands of transient dependencies. Have you ever (1) worked on a React app and (2) vetted all of React's 829 dependencies yourself? It's not remotely feasible. The only solution becomes "then don't use React!" - is this the best we can do?
      - RSZC 8y ago
        React does not have hundreds of dependencies: └─┬ react@16.6.3 ├─┬ loose-envify@1.4.0 │ └── js-tokens@4.0.0 ├── object-assign@4.1.1 ├─┬ prop-types@15.6.2 │ ├── loose-envify@1.4.0 deduped │ └── object-assign@4.1.1 deduped └─┬ scheduler@0.11.2 ├── loose-envify@1.4.0 deduped └── object-assign@4.1.1 deduped
        LeoNatan25 8y ago
        React Native then. 1200+ last I remember.
      - 8y ago
- pmoriarty 8y ago
  Users have to come to grips with the possibility that the "free" code they download might be malicious. To mitigate the risk they have these options: 1 - Don't use the software. 2 - Audit the software themselves before they use it. 3 - Pay someone to do the auditing for them. Even if they choose options 2 or 3, there's still a chance the some vulnerability of malware could sneak through (especially if they're getting a binary blob or source code written in a language like C that makes obfuscation easy). But if they choose to use unaudited software, they're playing with fire and shouldn't be surprised if from time to time they get burnt.
  - rapnie 8y ago
    I wonder if there are projects out there for an option 4: 4) Use an OSS dependency checker tool that reports the risk in your dependency tree 4a) Dependency tool uses a crowdsourced database of audit/review metrics A typical NodeJS project has potentially 1,000's of (transitive) dependencies. Many well-established projects use dependencies versioned e.g. 0.0.1 etc. I guess there are hundreds of similarly unmaintained packages among these. Lacking 4) a small-time developer working on a side-project only has option 1) (or option 0 - Take the risk) as a feasible way to go.
  - wstuartcl 8y ago
    Users have to come to grips with the possibility that the "free" code they download might be malicious. denial, anger, bargaining, depression and acceptance. ^^^^^
- aikah 8y ago
  People are dealing with a lot of negativity in their life, they shouldn't have to deal with that entitled bull-crap online, especially when doing unpaid work. Should the maintainer have been more cautious? no, he should have straight out closed the project and just ask people to fork it or use something else. If you are not going to maintain something anymore, don't even bother worrying about passing the torch. That way nothing is your responsibility anymore. The people who complain, insult the maintainer in Github issues right now will be at the root of a shift of mindset from contributors that will end the "golden age of open source".
  - kylecordes 8y ago
    I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. Then in the original project you can say “the last version of this project is N.N; here are some possible candidate successor forks, which have not been vetted”. This way no one who is merely keeping up with version numbers will accidentally step off of a reasonably good package on to a fraudulent package.
    - Novashi 8y ago
      >I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. To prescribe some preventative advice based on this: it's probably not a good idea if your project gets popular to continue being a solo developer in open source. So plan ahead based on your popularity. And your project isn't likely to explode in popularity over-night and be a dependency for 1000+ other projects, so you should be able to see this coming. Of course, this is super-easy to prescribe in hindsight.
    - wpietri 8y ago
      I 100% guarantee you that if he did that, he'd be getting a lot of static about how he should have handed the package over to some contributor.
- Y7ZCQtNo39 8y ago
  It's impractical, on an individual level, to vet your entire dependency tree. Installing something like react alone will put 100+ modules in your dependency tree. A more mature project will have a 4-figure number of dependencies. Things like Node Security Platform (which was absorbed by NPM) exist for a reason. There's no reason for every person to vet every single package they use -- it'd be an awful lot of duplicated energy. If there was no implicit trust in the community, and we had to act as vigilant as you describe, there would be no community.
  - reitzensteinm 8y ago
    This is a bit of a strawman. It absolutely is your responsibility, but that doesn't mean you can't outsource it.
    - Y7ZCQtNo39 8y ago
      It's the kind of thing where, if everyone with this problem chipped in $5/month, we could have a central repository of vulnerabilities. So, not absolving yourself of responsibility, but also way more efficient to outsource.
  - RSZC 8y ago
    (React does not have 100 dependencies, it has 5 including indirect dependencies)
    - deleted 8y ago
      [deleted]
    - Y7ZCQtNo39 8y ago
      A more mature project wouldn't have just React as a dependency. Point is, it's a lot of code to vet. React may have 5 indirect dependencies, but in my projects, I have 30 or more direct dependencies.
- coleifer 8y ago
  I experienced a twist on this. A guy who had very different aesthetic taste wanted me to merge some patches. He got real entitled about it, eventually I banned him. THEN he did the "appeal to Twitter" and made malicious edits to the project page on wikipedia. He made a huge stink and wasted hours of both of our time. It was unreal! I wish I was joking. I wrote about it, discussing my motivations for open source: http://charlesleifer.com/blog/your-idea-sucks/ http://charlesleifer.com/blog/your-idea-sucks/
  - danso 8y ago
    A. Damn, I would think a CTO would know to quit this dispute and fork his own purportedly superior version, if his company's survival is so dependent on it. B. Really like the elegant style (visually, though the writing is also elegant!) of your blog.
  - glogla 8y ago
    You shouldn't have hidden his name. We should know who it is, in case we meet him or something.
    - coleifer 8y ago
      Then I'd be doing exactly what he did, just dressed up a little in a blog instead of twitter.
      - glogla 8y ago
        No. Complaining about horrible behavior is not horrible behavior about itself.
- jxramos 8y ago
  I caught that notion they had > I've shared publish rights with other people before. Of course, If I had realized they had a malicious intent I wouldn't have, but at the time it looked like someone who was actually trying to help me. Can anyone cite perhaps a handful of examples where this malicious open source usage ultimately bit them?
- mwfunk 8y ago
  Well they certainly couldn't call it "free software", that involves many more assumptions than "Open Source", and it might not even be free of charge. :) Blame Richard Stallman for using an incredibly common word with many meanings to refer to something that has one incredibly specific meaning which is unintuitive to most people, and to pretty much anyone who isn't a developer. I think several decades of Open Source boosterism may have eventually given some people the wrong idea about what it's all about. Two annoying trends I've noticed in the last 10 years: (1) (what this poor guy seems to be running into) People treating Open Source as anything other than charity from the people who put it out there. The people who make it generally don't owe anyone anything, including the people who use their code. I sometimes see very harsh criticism from people within the community that assumes anyone putting anything out there has to accept all sorts of responsibilities: maintaining a community, keeping on top of bug reports, acting as an integrator for people who want to send in patches, making sure that all packaging and documentation conform to some very high bar and/or specification, etc. Just because somebody puts something out there doesn't mean it has to be a second job for them, and doesn't mean that they are obligated to do anything for anyone, including responding to emails or dealing with bug reports or patches. It's perfectly fine to stop maintaining something after a while, or to just throw code over the wall and never touch it again after it's out there. (2) (not this case) People treating Open Source as some avenue to professional fame or an eventual source of income. Yeah, that can happen, but it very rarely happens, and it's not a good reason to write it in the first place. This is the result of too many people using business arguments as a fundamental justification for doing Open Source, and people saying stuff like they only hire people who have projects on Github, and only if they like what they see. If someone's primary motivation is fame or money, Open Source is a terrible way to accomplish that. It's possible, just highly unlikely, plus I think it's much less likely to happen if that's someone's goal from the outset.
  - jungler 8y ago
    I think there is an underlying root cause to how we treat Open Source, and it's similar to the IT "cost center vs value creator" problem: Open source packages are treated as consumer goods, and creators in turn will engage with that by marketing them as consumable products. Many of these things which are distributed as packages are actually code snippets. They could be maintained in the form of a Stack Overflow answer to copy-paste into your code. The question-answer system exposes the code to the necessary competitive evaluation: a malicious answer soon gets downvoted. When the packaging metaphor is laden over them, the whole chain of responsibility lapses back to the vendor-consumer model. And this works when packages are large and take pains to reduce their own dependencies, even if it means common functions get duplicated across different packages. But prolific authors currently are rewarded by being vendors of undersized packages: they enjoy large download numbers, Github stars, and so on. Without any kind of curation to impose friction on this process, they can do the wrong thing for a very long period and get zero feedback indicating that their actions create a problem. And on the consuming side nobody pays a lick of attention when the prompt says it's going to install 50 things with cute-but-opaque names. If they are under a page of code each, you could probably just print the code. When I create projects now, I tend to grab some packaged code to start with, but apart from a few to do core functions like I/O I will treat them as placeholders and seek ways of reworking the code to make myself the sole maintainer. The alternative is to be a software consumer and to complain like a consumer - i.e. in a largely powerless fashion - when other people's code doesn't do what I want.
- B-Con 8y ago
  > Maybe calling free software "Open Source" was a mistake. This conflation is definitely a bad thing. Words with an actual meaning get over-used, simplified, stripped of their original meaning, and then merged. It would be 100% to the detriment of our language if it happens in this case. Open source does not mean free (as in freedom or beer), free (as in beer) does not mean open source. Free as in freedom almost always means open source. Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source.
  - type0 8y ago
    > Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source. How true, this is such a common misunderstanding among newcomers to FOSS, it can't be repeated enough times.
- sytelus 8y ago
  This problem can be solvable by introducing “Verified Identity” on GitHub. Anyone who wants to be maintainer of popular project can be asked to get Verified Identity. If this person turned out to be malicious, he risks getting tracked down by law enforcement fairly easily. For getting Verified Identity, simplest thing might be validation of phone number. Bit more complex thing might be Verified bank account or credit card. Assuming GitHub has 1M active users and each user verification costs $5, the cost of solving this problem is less than 0.1% of GitHub valuation but can hugely improve trust levels.
  - jdorfman 8y ago
    Good idea although $5 to a person writing malicious code and out of jurisdiction isn't much of a deterrent IMO.
  - peterbraden 8y ago
    Why on earth would anyone want to be on the hook for liability like this for an unpaid maintenance job? Open source licenses state this clearly: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND"
- AsyncAwait 8y ago
  Agree with you, just note that the term "free software" doesn't actually refer to software price at all.
- type0 8y ago
  > Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. Since no one seems to care about the freedom aspect of it, maybe we could rename it to "fee software" - give it away for free and encourage everyone to contribute with time and money. Will people stop being selfish because we changed the name? I don't think so.
codezero 8y ago
I feel bad for the guy, he's not wrong, that's for sure, but a recent example of "doing this right" is here: https://news.ycombinator.com/item?id=18525025 https://news.ycombinator.com/item?id=18525025 / https://github.com/FineUploader/fine-uploader/issues/2073 https://github.com/FineUploader/fine-uploader/issues/2073 (FineUploader is shutting down) At least, it seems that way to me. If I were ever in a burdensome positioning of maintaining a package I didn't want to maintain, I'd go for the explicit archive/sunset route. At that point if someone wants to fork and re-package, they can do it, but it won't mess with anything directly downstream immediately.
madrox 8y ago
Anyone blaming Dominic for not being more responsible should blame themselves for the same reason. This isn't the first time Node has had horrible dependency issues. Have we forgotten left pad? https://news.ycombinator.com/item?id=11340510 https://news.ycombinator.com/item?id=11340510 Ultimately, you can't take dependencies for granted.
- bendmorris 8y ago
  >Ultimately, you can't take dependencies for granted. The problem is that JS dependencies are so modular that shifting the burden to vet your dependencies to developers is generally not realistic. Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that? To compound things, this package could be a transient dependency of a transient dependency, so I may not even know the person who decided to depend on it in the first place, or the reason why, or what the package does. It's not that people are taking dependencies for granted - it's that there is no reasonable alternative.
  - starbeast 8y ago
    Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked.
    - bendmorris 8y ago
      I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing. Stack (https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.
    - PeterisP 8y ago
      This also has security implications as in this approach you don't get the fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you may be vulnerable to a takeover like this (which happen but are rare), but if you're still running 1.2.3 when 1.2.4 is out, you're definitely vulnerable to all the things that 1.2.4 fixed, and these risks are far more common. If semantic versioning always behaved as it should be, the default shouldn't be the last thing that worked but rather the major/minor version of the last thing that worked followed by the latest and greatest patch version.
preommr 8y ago
Is there even a generalized guideline on how to handover npm packages? It would seem like common sense to let something die and let any new interested maintainers fork the project thank to just wantonly hand it over to a complete stranger. But I could easily see someone getting into the habit of trusting people and not thinking about it too much. Maybe a combination of better guidelines, some kind of code of ethics along with better means of communicating these changes through npm would've helped this issue a lot more. If not to actually prevent the problem then to at least have some ground to hold people accountable other than accusations of people should know better.
- runarberg 8y ago
  Perhaps you should suggest these guidelines: https://npm.community/ https://npm.community/
- deleted 8y ago
  [deleted]
peteradio 8y ago
Why wasn't NPM monitoring for this kind of behavior? I guess it wouldn't catch all bad behaviors but this is just asking for it.
pmoriarty 8y ago
I've written a lot of software in my life -- almost all of it for myself, and I just never bothered to open source most of it, because if I'm going to open source it I want to make a good impression, so I want to clean up the code and write some docs and make sure it it builds ok for others, think of a name for it, upload it somewhere, etc. It's just so much easier to keep it for myself and not bother with any of that. Despite all this, I have open sourced a couple of things here and there. Little things. Things that virtually no one ever used, as far as I know. But once I did get a very polite feature request from someone on something that I'd moved on from, so I told them I wouldn't do it. That was more than a decade ago, and I still think about it and feel kind of guilty for not doing it.. even though I know I have nothing to feel guilty about. I can imagine being the author or maintainer of a popular package must be like this times a thousand. You have to put up with so much negativity and pressure from people who demand you do work for them for free. I feel for these people. Anyone who spends even the smallest fraction of their life to give a gift to the world does not deserve anything but praise from those who benefit from it.
- type0 8y ago
  > Despite all this, I have open sourced a couple of things here and there. Little things. Things that virtually no one ever used, as far as I know. You wouldn't know, when learning every help and every practical example can be useful. I understand that not everyone likes to learn by reading someones code but it can be invaluable especially for students in places where books are prohibitively expensive compared to the living standards. You're doing good deed, even if it's just small things, but make sure to document it properly.
ngcc_hk 8y ago
A free gift like fire to mankind can be both great if useful and bad if misused. Just nature. And the being helped it forever have an eagle chasing his liver ... or he has to do the stone.
classichasclass 8y ago
I have a rule I don't maintain software I don't personally use. It's kept me from picking up projects other people ask me to do for them, and it's been a good dividing line when it's time to hang it up. I think his major mistake wasn't advertising he'd moved on, and I feel badly for the heat he's taking.
davej 8y ago
Personal attacks are completely unwarranted. I think a more useful (and certainly more constructive) way to look at this is to frame it as a learning experience and figure out what we can do to minimize the effect of this in future. It's almost impossible to vet every sub-sub dependency of a large codebase without dedicating huge resources. Perhaps there needs to some sort of a javascript code signing standard that requires a level of user identity verification. This is a solved problem with Authenticode and Gatekeeper for executables on Windows/Mac. We have been able to hide behind the fact that we're devs (we know what we're doing!!), but many consumer-level applications (mainly Electron-based) now run node modules with user-level (or higher) permissions. Maybe we need to become a bit more diligent in this area and look at less ad-hoc ways of managing dependencies and identity verification.
bit_logic 8y ago
The community discussion is focused on the wrong thing. Here is the problem: https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-stream Look at that URL. It has "dominictarr" in it. Now click on the URL. Look at the big "dominictarr/event-stream" in the upper left of the screen. Many are going to conclude that this package belongs to dominictarr. Almost everything in the UI indicates this. Developers don't trust code, they trust people and organizations. NPM and Github needs to make it very clear when ownership has changed. And needs defaults that properly inform all users when ownership has changed. For example, when I SSH into a server the first time, it asks if I trust the key. Then one day, what if it asks again? Then I can stop and investigate why the key has changed, what's going on, and if I should trust it again. With the current NPM/Github there's no warning to users. A developer could've checked dominictarr's background and decide they are trustworthy, which would then extend to event-stream as well. But where's the warning to users when ownership of event-stream has changed and they need to re-evaluate whether to trust the new owner? And why does it look like the project still belongs to dominictarr when it actually doesn't? Those are the key issues here.
- trickstra 8y ago
  > Developers don't trust code, they trust people well the code doesn't write itself, so partially true. But ultimately it's about accountability. If Dominic himself added the backdoor, his presence in the community would end that day. If an anonymous alias does that, we don't even know who to blame. Dominic's fault is not the backdoor, but the irresponsibility of handing over a used package to an anonymous alias. Not being clear about the fact that the package is abandoned. I wouldn't depend on an abandoned package, if I knew that.
  - QuantumGood 8y ago
    > Not being clear about the fact that the package is abandoned This is really the key point here.
- always_good 8y ago
  The NPM organization could go much further to make these attacks harder. You pitch a really good one: Any time you npm update/install, display ownership changes (especially compared to your prev version). Another one is to show the source code on the NPM website itself instead of hiding it in a tarball. NPM basically trains people to assume the published code == the code at the linked repository. It's a hacky honor system that only helps attackers.
matte_black 8y ago
So much good software out there is forever hidden from the world because the creators are afraid to be seen failing publicly, because of shit like this. To the brave souls who release open source packages, here’s to you.
danso 8y ago
I agree that the author has every right to quit being a maintainer, for any reason, but I don't believe that he is necessarily absolved of all judgment just because it was a free project he did on his own time. He's obviously a prolific and generous author, but that experience also means he's very aware about real-world practices (especially in the npm ecosystem) to know that ceding control of a popular library, without taking any precaution, has the potential to put a significant number of users at risk. Should the users be less complacent? Sure, but that's not currently the world we live in, and the author is not ignorant of that. If an experienced electrician volunteers his time to a homeless shelter, and decides to quit halfway through a rewiring project, it's his right to quit whenever. But the manner in which he leaves the project is also important. There's a huge difference between: - Confronting the shelter manager and saying "Hey, I can't do this anymore, and you get a professional ASAP to fix my work because I can't guarantee that I've properly grounded everything" - Exchanging pleasant goodbyes with the shelter staff, and not giving them any reason to worry about what you may or may not have done. The latter situation is akin to a silent failure -- even stomping off the job and telling the shelter to go fuck themselves is ultimately preferable, since the shelter staff at least are very aware that your work may be dangerously unfinished. While you may not be liable if anyone gets shocked/electrocuted from your leftover work, that doesn't mean the shelter staff are obligated to not grumble and warn anyone else who might be relying on you for volunteer work. edit: that said, I don't have a major objection to the author's response, as submitted here. I was referring to people who think that any significant criticism is unwarranted, just because the work is free. The author, to his credit, made a decently detailed reply and continues to make thoughtful responses.
- mehrdadn 8y ago
  I think your example makes your point weaker rather than stronger, because unlike the electrician, this guy has no reason to believe he's done a bad by job himself, because he's not putting anyone's life in danger, and because others who are using his work are also supposed to be similar professionals in their technical fields and taking similar responsibility. Comparing it to laymen who know potentially nothing about secure wiring getting potentially electrocuted because of a malpracticing electrician is not a great comparison.
brians 8y ago
And this is why professionals didn’t depend on build-time fetch of dependencies.
Domenic_S 8y ago
> There are too many NPM packages, and worse, too many people quick to add as many dependencies as possible, resulting in crazy dependency trees that you should never actually see in the wild. Additionally, it seems to only be in the node ecosystem that you see single authors with hundreds of packages. Why they do this, I do not know... Because javascript has a weak standard library.
- PhilWright 8y ago
  Maybe the most popular small libraries should be merged together into a single library that can be used to reduce the number of dependencies, in the hope it can become a standard. Like a jQuery for npm.
  - kangax 8y ago
    I think that was the motivation of https://js.foundation https://js.foundation
- zaphar 8y ago
  Nah it's less about the standard library and more about the fact that Javascript doesn't have dead code removal so keeping a package small is one way to ensure you aren't pulling in code you aren't going to use. Of course the failure mode here is that you if you still choose a batteries included framework. (i.e. Angular, or a React powered framework) you end up pulling in a whole bunch of code you don't use and the list of dependencies is unmanageable. But because javascript was born in the browser and most javascript still has to be shipped to a browser it has constraints most other languages do not.
nkkollaw 8y ago
I read this: https://github.com/dominictarr/event-stream/issues/116#issuecomment-440927400 https://github.com/dominictarr/event-stream/issues/116#issue..., which might seem controversial, but what was he supposed to do? I guess just let it rot and tell people to fork.
notacoward 8y ago
So much for "many eyes make all bugs shallow" I guess. Problem is that 99% of those eyes are turned only toward using the product of someone else's good will for their own personal profit. And 99% of the remainder are only looking for bugs in the features they use, or just aren't that good at spotting bugs. This only gets worse in environments like NPM, which make it easy for dependencies to proliferate beyond anyone's expectations, so people don't even know what code they should be looking at. This is still better than the situation with proprietary software, but problems like these are kind of inevitable in an ecosystem where people typically write 5% of the code themselves and blindly pull in the other 95% from who knows where via unchecked package dependencies.
- wtracy 8y ago
  Those "many eyes" are the reason this was caught at all. I could easily imagine situations where this backdoor would go unnoticed for months or years.
  - notacoward 8y ago
    Some tiny subset of those many eyes might have found it, but by then its impact was far from shallow. In some open-source ecosystems (e.g. GNU or BSD) the ratio of useful eyeballs to vulnerable ones is much higher. It almost seems to be a goal of NPM to maximize the blast radius before a problem is noticed. That's not a healthy way to manage open-source projects.
kylecordes 8y ago
I have observed an ongoing pattern. People who create a thing (that becomes somewhat popular) in some sense get credit for it. They are mentioned as the creator of it, forever. It becomes part of their resume, their online reputation. Perhaps they go on to create another thing. This happens to a far lesser extent for people who adopt a project later to become an ongoing maintainer. A project might have an originator who works hard for six months, and rewarded forever, and some maintainers who work hard for six years and gets very little reward. Out of respect for many people who do great work, I will not name names. :-)
purplezooey 8y ago
Makes you wonder if we are at Peak Open Source
- ralph84 8y ago
  The largest pure-play open source company and the largest open source host both being acquired within the last 6 months is a strong indication.
flocial 8y ago
I don't know what it is about the current environment but it pains me to see people get the life sucked out of them for sharing code and making the world a better place. It's also equally disheartening to see prominent open source contributors essentially close their social media because they're constantly hounded by entitled "community" members and trolls.
raphlinus 8y ago
I think this is a major loss of innocence moment for open source. The only sustainable solution to this sort of problem is to pay people to do at least minimal curation and maintenance of open source libraries. In an ideal world, the payment would go to people who actually create open source value. However, I'm cynical enough about human nature and business to suspect that it will mostly go to middlemen like record distributors and academic publishers, who create very little actual value but somehow make themselves indispensable in the ecosystem.
udithishara 8y ago
> If I had realized they had a malicious intent I wouldn't have Welcome to the Internet There are people buying chrome extensions, so they could inject something else this guy is surprised when someone did it to his project, which he handed over for free
_nalply 8y ago
I found this comment insightful: https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a#gistcomment-2769564 https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36... Summary: 1. Mark as deprecated 2. Change the name by adding "-archived" 3. Turn off Github issues 4. Give away ownership if there is at least a mini-community
- ship_it 8y ago
  but noo, uh .. my fame!!! :'( cries in npm
carapace 8y ago
So NPM users et. al. are a hoard of unwashed children. This is like Lord of the Flies.
jeswin 8y ago
Dominic is a prolific contributor and compassionate leader in the JS and P2P communities - and it was a disheartening thread to read. The suggestions that he (working for free!) should have done more seemed unfair. We should look to fix these: - If we're going to rely on hundreds of packages per project, we need fine grained security like Android or iOS. deno seems to be doing node right - https://github.com/denoland/deno/issues/171 https://github.com/denoland/deno/issues/171 - Lock down versions for now. Use 1.2.1 instead of ~1.2.1 or ^1.2.1. - If npm must remain at the center of node's module system, they might have to add auditing and approval tools. 'npm install' can warn about unaudited modules. The problem with that is that it will make npm (a business) even more central to the node ecosystem - which may not be a good thing.
jahaja 8y ago
However you frame it, a very widely used package management system based essentially on trust and a community that doesn't expect any amount of responsibility with regards to those packages seems like a bad combination.
bytematic 8y ago
That was incredibly well written and I believe him truly. I had not considered that the amount of these tiny packages was probably people trying to learn.
mmgutz 8y ago
I dont get why the original author is getting so much flack. This is a problem with semver and npm. I hope versions are immutable on npm.
- aequitas 8y ago
  You could argue he could have done a better job in communicating he and his reputation is no longer what is behind this project. But that it has moved to someone else.
magma17 8y ago
the quid is if the maintainer is a douchbag or not
draw_down 8y ago
This whole debacle has really demented my thought that I would probably never maintain an open source project. There is so much downside.
randomsearch 8y ago
This is a little orthogonal, but I'd really appreciate thoughts on this: Is FOSS a good idea? I've always assumed yes. Think of all the libraries in the Python ecosystem, for example. I've used them to build tons of things, even a couple of things that made a little money and allowed me to get myself a new laptop. I've written open source projects myself, filed issues and helped fix bugs in others. The code I've written represents a lot of time, and I'm happy to give it away. Think about Linux, and what it has done for the world. I've used it for non-commercial purposes all over the place, and it's made research and teaching I've been involved in much easier; it may have been impossible to achieve many things without it. But recently I've begun to question the idea of FOSS, sparked by Jaron Lanier's concerns. There's something clean about paying someone for their software: you have an entity responsible for the code, you can pay for support, you have recourse if you need it. There are clear incentives and rewards, and money earned is properly redistributed. I know that companies like Google do a lot for FOSS, but it's probable that their contributions are minuscule compared to the monetary value they have extracted from it. The alternative is not closed-source: e.g. with web dev you can provide the source code but charge for licensing, etc. So it's more about "free" vs "non-free" than "open" vs "closed". The idea of people coding for free is quite an odd one. Imagine if the world's graphic designers en masse started providing millions of free designs covering every possible icon and situation? (I'm aware of small examples, but they're not at the scale of OSS). Designers don't do it. You would make a lot of people redundant overnight - not all designers, but a lot of them. What do people think? I can't see how we could have this amazing ecosystem without FOSS... but maybe some kind of transactional funding model is needed to make it sustainable, more secure, etc. My instincts were for FOSS, but there's often a difference between what sounds beautiful conceptually and the problems of how it works in practice. RMS' ideas were very attractive, but then you see the modern world from a musician's point of view and it sucks - the long-term effects of ignoring copyright have been to diminish income for musicians. Whilst I improve my friend's quality of life by giving them a copy of some music, their kids might grow up in a world with less good music as a result. I know the record industry sucked, but free copying is not the only alternative. I'd really appreciate input here, as I have failed to resolved this either way. Thoughts?
gumby 8y ago
Always makes me think of Brian Fox's canned response to people who flamed him about bash: "Please return your copy of bash for a full refund."
devxpy 8y ago
What happened to tidelift? https://tidelift.com/ https://tidelift.com/
ptx 8y ago
"Since the early days of node/npm, sharing commit access/publish rights, with other contributors was a widespread community practice. https://felixge.de/2013/03/11/the-pull-request-hack.html https://felixge.de/2013/03/11/the-pull-request-hack.html open source is driven by sharing! It's great!" Yes, but, quoting from his post he cites: "So should you really do this for all pull requests? Probably not. While I've given a large amount of users access to various projects of mine, I'm still looking for: "Github profile: Does this user stand to lose a reputation by doing something stupid? "Skill: Based on the patch, do I think the user could be a good developer? "Usefulness: Is this patch solving a valid problem?"

317 points by jashkenas 8y ago

drwl 8y ago

This references https://news.ycombinator.com/item?id=18534392 https://news.ycombinator.com/item?id=18534392 It looks like it's title has been changed from when I first read it.

jashkenas 8y ago
Yep. I submitted it with "Dominic Tarr’s Statement on the hacker hijacking of the event-stream NPM module", which was as descriptive of a title as I could think of quickly. It looks like the moderators have dinged the submission and changed it to: "If it's not fun anymore, you get nothing from maintaining a popular package" ... which I think we can all agree is generic, and fails to make the connection to the big news of the day. It may just be whispering into the wind, but if the mods are listening — how about "Dominic Tarr: statement on event-stream compromise", which uses the Gist's description, and helps folks know what this link is all about?

gwicks56 8y ago

Personally I felt people on GitHub were being way too harsh. He built something, moved on, and gave it away. He had no way of knowing the person who took it over would use it maliciously. Seriously, some of the comments blew my mind. Because he built it, he had a responsibility to maintain it forever, and was responsible for everything that happened with that code forever? Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. If you are using somebody else's code, is it their responsibility to look after it years after they have moved on, or your responsibility to make sure it's not full of bugs or malicious code.

madrox 8y ago
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.
tathougies 8y ago
The entitlement mentality of some people is insane.
- tonyedgecombe 8y ago
  Especially when they aren't paying.
vernie 8y ago
Sayre's law, baby.
- QuantumGood 8y ago
  Intensity of feeling is inversely proportional to issue value sometimes. Recent US political discourse seems to violate Sayre's law.
bendmorris 8y ago
>He had no way of knowing the person who took it over would use it maliciously. Then it was, clearly, negligent of him to give it to this person. He gave a stranger the power to do things in his name. He doesn't have to maintain the project forever - it seems like a much easier solution is: don't give away a project with your name on it to someone you don't know. Instead, encourage them to fork and release a new version under their own name. This is a surefire way to never have an exploit spread to thousands of people with your name on it.
- runarberg 8y ago
  As a user of free software you should always accept the risk that it is maintained by a malicious actor. It is just as likely that the original author will turn malicious. You as a user have the responsibility of auditing all the free software you use.
  - bendmorris 8y ago
    People keep casually making this suggestion. In JS this can involve hundreds or thousands of transient dependencies. Have you ever (1) worked on a React app and (2) vetted all of React's 829 dependencies yourself? It's not remotely feasible. The only solution becomes "then don't use React!" - is this the best we can do?
    - RSZC 8y ago
      React does not have hundreds of dependencies: └─┬ react@16.6.3 ├─┬ loose-envify@1.4.0 │ └── js-tokens@4.0.0 ├── object-assign@4.1.1 ├─┬ prop-types@15.6.2 │ ├── loose-envify@1.4.0 deduped │ └── object-assign@4.1.1 deduped └─┬ scheduler@0.11.2 ├── loose-envify@1.4.0 deduped └── object-assign@4.1.1 deduped
      - LeoNatan25 8y ago
        React Native then. 1200+ last I remember.
    - 8y ago
pmoriarty 8y ago
Users have to come to grips with the possibility that the "free" code they download might be malicious. To mitigate the risk they have these options: 1 - Don't use the software. 2 - Audit the software themselves before they use it. 3 - Pay someone to do the auditing for them. Even if they choose options 2 or 3, there's still a chance the some vulnerability of malware could sneak through (especially if they're getting a binary blob or source code written in a language like C that makes obfuscation easy). But if they choose to use unaudited software, they're playing with fire and shouldn't be surprised if from time to time they get burnt.
- rapnie 8y ago
  I wonder if there are projects out there for an option 4: 4) Use an OSS dependency checker tool that reports the risk in your dependency tree 4a) Dependency tool uses a crowdsourced database of audit/review metrics A typical NodeJS project has potentially 1,000's of (transitive) dependencies. Many well-established projects use dependencies versioned e.g. 0.0.1 etc. I guess there are hundreds of similarly unmaintained packages among these. Lacking 4) a small-time developer working on a side-project only has option 1) (or option 0 - Take the risk) as a feasible way to go.
- wstuartcl 8y ago
  Users have to come to grips with the possibility that the "free" code they download might be malicious. denial, anger, bargaining, depression and acceptance. ^^^^^
aikah 8y ago
People are dealing with a lot of negativity in their life, they shouldn't have to deal with that entitled bull-crap online, especially when doing unpaid work. Should the maintainer have been more cautious? no, he should have straight out closed the project and just ask people to fork it or use something else. If you are not going to maintain something anymore, don't even bother worrying about passing the torch. That way nothing is your responsibility anymore. The people who complain, insult the maintainer in Github issues right now will be at the root of a shift of mindset from contributors that will end the "golden age of open source".
- kylecordes 8y ago
  I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. Then in the original project you can say “the last version of this project is N.N; here are some possible candidate successor forks, which have not been vetted”. This way no one who is merely keeping up with version numbers will accidentally step off of a reasonably good package on to a fraudulent package.
  - Novashi 8y ago
    >I think this is the clearest, easiest, correct answer. If you no longer have the time and motivation to maintain a project, and are also not in a position to hand over control to someone you have good reason to trust, the easy, safe answer is to retire it, and have others fork. To prescribe some preventative advice based on this: it's probably not a good idea if your project gets popular to continue being a solo developer in open source. So plan ahead based on your popularity. And your project isn't likely to explode in popularity over-night and be a dependency for 1000+ other projects, so you should be able to see this coming. Of course, this is super-easy to prescribe in hindsight.
  - wpietri 8y ago
    I 100% guarantee you that if he did that, he'd be getting a lot of static about how he should have handed the package over to some contributor.
Y7ZCQtNo39 8y ago
It's impractical, on an individual level, to vet your entire dependency tree. Installing something like react alone will put 100+ modules in your dependency tree. A more mature project will have a 4-figure number of dependencies. Things like Node Security Platform (which was absorbed by NPM) exist for a reason. There's no reason for every person to vet every single package they use -- it'd be an awful lot of duplicated energy. If there was no implicit trust in the community, and we had to act as vigilant as you describe, there would be no community.
- reitzensteinm 8y ago
  This is a bit of a strawman. It absolutely is your responsibility, but that doesn't mean you can't outsource it.
  - Y7ZCQtNo39 8y ago
    It's the kind of thing where, if everyone with this problem chipped in $5/month, we could have a central repository of vulnerabilities. So, not absolving yourself of responsibility, but also way more efficient to outsource.
- RSZC 8y ago
  (React does not have 100 dependencies, it has 5 including indirect dependencies)
  - deleted 8y ago
    [deleted]
  - Y7ZCQtNo39 8y ago
    A more mature project wouldn't have just React as a dependency. Point is, it's a lot of code to vet. React may have 5 indirect dependencies, but in my projects, I have 30 or more direct dependencies.
coleifer 8y ago
I experienced a twist on this. A guy who had very different aesthetic taste wanted me to merge some patches. He got real entitled about it, eventually I banned him. THEN he did the "appeal to Twitter" and made malicious edits to the project page on wikipedia. He made a huge stink and wasted hours of both of our time. It was unreal! I wish I was joking. I wrote about it, discussing my motivations for open source: http://charlesleifer.com/blog/your-idea-sucks/ http://charlesleifer.com/blog/your-idea-sucks/
- danso 8y ago
  A. Damn, I would think a CTO would know to quit this dispute and fork his own purportedly superior version, if his company's survival is so dependent on it. B. Really like the elegant style (visually, though the writing is also elegant!) of your blog.
- glogla 8y ago
  You shouldn't have hidden his name. We should know who it is, in case we meet him or something.
  - coleifer 8y ago
    Then I'd be doing exactly what he did, just dressed up a little in a blog instead of twitter.
    - glogla 8y ago
      No. Complaining about horrible behavior is not horrible behavior about itself.
jxramos 8y ago
I caught that notion they had > I've shared publish rights with other people before. Of course, If I had realized they had a malicious intent I wouldn't have, but at the time it looked like someone who was actually trying to help me. Can anyone cite perhaps a handful of examples where this malicious open source usage ultimately bit them?
mwfunk 8y ago
Well they certainly couldn't call it "free software", that involves many more assumptions than "Open Source", and it might not even be free of charge. :) Blame Richard Stallman for using an incredibly common word with many meanings to refer to something that has one incredibly specific meaning which is unintuitive to most people, and to pretty much anyone who isn't a developer. I think several decades of Open Source boosterism may have eventually given some people the wrong idea about what it's all about. Two annoying trends I've noticed in the last 10 years: (1) (what this poor guy seems to be running into) People treating Open Source as anything other than charity from the people who put it out there. The people who make it generally don't owe anyone anything, including the people who use their code. I sometimes see very harsh criticism from people within the community that assumes anyone putting anything out there has to accept all sorts of responsibilities: maintaining a community, keeping on top of bug reports, acting as an integrator for people who want to send in patches, making sure that all packaging and documentation conform to some very high bar and/or specification, etc. Just because somebody puts something out there doesn't mean it has to be a second job for them, and doesn't mean that they are obligated to do anything for anyone, including responding to emails or dealing with bug reports or patches. It's perfectly fine to stop maintaining something after a while, or to just throw code over the wall and never touch it again after it's out there. (2) (not this case) People treating Open Source as some avenue to professional fame or an eventual source of income. Yeah, that can happen, but it very rarely happens, and it's not a good reason to write it in the first place. This is the result of too many people using business arguments as a fundamental justification for doing Open Source, and people saying stuff like they only hire people who have projects on Github, and only if they like what they see. If someone's primary motivation is fame or money, Open Source is a terrible way to accomplish that. It's possible, just highly unlikely, plus I think it's much less likely to happen if that's someone's goal from the outset.
- jungler 8y ago
  I think there is an underlying root cause to how we treat Open Source, and it's similar to the IT "cost center vs value creator" problem: Open source packages are treated as consumer goods, and creators in turn will engage with that by marketing them as consumable products. Many of these things which are distributed as packages are actually code snippets. They could be maintained in the form of a Stack Overflow answer to copy-paste into your code. The question-answer system exposes the code to the necessary competitive evaluation: a malicious answer soon gets downvoted. When the packaging metaphor is laden over them, the whole chain of responsibility lapses back to the vendor-consumer model. And this works when packages are large and take pains to reduce their own dependencies, even if it means common functions get duplicated across different packages. But prolific authors currently are rewarded by being vendors of undersized packages: they enjoy large download numbers, Github stars, and so on. Without any kind of curation to impose friction on this process, they can do the wrong thing for a very long period and get zero feedback indicating that their actions create a problem. And on the consuming side nobody pays a lick of attention when the prompt says it's going to install 50 things with cute-but-opaque names. If they are under a page of code each, you could probably just print the code. When I create projects now, I tend to grab some packaged code to start with, but apart from a few to do core functions like I/O I will treat them as placeholders and seek ways of reworking the code to make myself the sole maintainer. The alternative is to be a software consumer and to complain like a consumer - i.e. in a largely powerless fashion - when other people's code doesn't do what I want.
B-Con 8y ago
> Maybe calling free software "Open Source" was a mistake. This conflation is definitely a bad thing. Words with an actual meaning get over-used, simplified, stripped of their original meaning, and then merged. It would be 100% to the detriment of our language if it happens in this case. Open source does not mean free (as in freedom or beer), free (as in beer) does not mean open source. Free as in freedom almost always means open source. Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source.
- type0 8y ago
  > Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source. How true, this is such a common misunderstanding among newcomers to FOSS, it can't be repeated enough times.
sytelus 8y ago
This problem can be solvable by introducing “Verified Identity” on GitHub. Anyone who wants to be maintainer of popular project can be asked to get Verified Identity. If this person turned out to be malicious, he risks getting tracked down by law enforcement fairly easily. For getting Verified Identity, simplest thing might be validation of phone number. Bit more complex thing might be Verified bank account or credit card. Assuming GitHub has 1M active users and each user verification costs $5, the cost of solving this problem is less than 0.1% of GitHub valuation but can hugely improve trust levels.
- jdorfman 8y ago
  Good idea although $5 to a person writing malicious code and out of jurisdiction isn't much of a deterrent IMO.
- peterbraden 8y ago
  Why on earth would anyone want to be on the hook for liability like this for an unpaid maintenance job? Open source licenses state this clearly: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND"
AsyncAwait 8y ago
Agree with you, just note that the term "free software" doesn't actually refer to software price at all.
type0 8y ago
> Maybe calling free software "Open Source" was a mistake. If something is "free", then you have to accept you may get what you paid for. Since no one seems to care about the freedom aspect of it, maybe we could rename it to "fee software" - give it away for free and encourage everyone to contribute with time and money. Will people stop being selfish because we changed the name? I don't think so.

codezero 8y ago

I feel bad for the guy, he's not wrong, that's for sure, but a recent example of "doing this right" is here: https://news.ycombinator.com/item?id=18525025 https://news.ycombinator.com/item?id=18525025 / https://github.com/FineUploader/fine-uploader/issues/2073 https://github.com/FineUploader/fine-uploader/issues/2073 (FineUploader is shutting down) At least, it seems that way to me. If I were ever in a burdensome positioning of maintaining a package I didn't want to maintain, I'd go for the explicit archive/sunset route. At that point if someone wants to fork and re-package, they can do it, but it won't mess with anything directly downstream immediately.

madrox 8y ago

Anyone blaming Dominic for not being more responsible should blame themselves for the same reason. This isn't the first time Node has had horrible dependency issues. Have we forgotten left pad? https://news.ycombinator.com/item?id=11340510 https://news.ycombinator.com/item?id=11340510 Ultimately, you can't take dependencies for granted.

bendmorris 8y ago
>Ultimately, you can't take dependencies for granted. The problem is that JS dependencies are so modular that shifting the burden to vet your dependencies to developers is generally not realistic. Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that? To compound things, this package could be a transient dependency of a transient dependency, so I may not even know the person who decided to depend on it in the first place, or the reason why, or what the package does. It's not that people are taking dependencies for granted - it's that there is no reasonable alternative.
- starbeast 8y ago
  Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked.
  - bendmorris 8y ago
    I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing. Stack (https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.
  - PeterisP 8y ago
    This also has security implications as in this approach you don't get the fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you may be vulnerable to a takeover like this (which happen but are rare), but if you're still running 1.2.3 when 1.2.4 is out, you're definitely vulnerable to all the things that 1.2.4 fixed, and these risks are far more common. If semantic versioning always behaved as it should be, the default shouldn't be the last thing that worked but rather the major/minor version of the last thing that worked followed by the latest and greatest patch version.

preommr 8y ago

Is there even a generalized guideline on how to handover npm packages? It would seem like common sense to let something die and let any new interested maintainers fork the project thank to just wantonly hand it over to a complete stranger. But I could easily see someone getting into the habit of trusting people and not thinking about it too much. Maybe a combination of better guidelines, some kind of code of ethics along with better means of communicating these changes through npm would've helped this issue a lot more. If not to actually prevent the problem then to at least have some ground to hold people accountable other than accusations of people should know better.

runarberg 8y ago
Perhaps you should suggest these guidelines: https://npm.community/ https://npm.community/
deleted 8y ago
[deleted]

peteradio 8y ago

Why wasn't NPM monitoring for this kind of behavior? I guess it wouldn't catch all bad behaviors but this is just asking for it.

pmoriarty 8y ago

I've written a lot of software in my life -- almost all of it for myself, and I just never bothered to open source most of it, because if I'm going to open source it I want to make a good impression, so I want to clean up the code and write some docs and make sure it it builds ok for others, think of a name for it, upload it somewhere, etc. It's just so much easier to keep it for myself and not bother with any of that. Despite all this, I have open sourced a couple of things here and there. Little things. Things that virtually no one ever used, as far as I know. But once I did get a very polite feature request from someone on something that I'd moved on from, so I told them I wouldn't do it. That was more than a decade ago, and I still think about it and feel kind of guilty for not doing it.. even though I know I have nothing to feel guilty about. I can imagine being the author or maintainer of a popular package must be like this times a thousand. You have to put up with so much negativity and pressure from people who demand you do work for them for free. I feel for these people. Anyone who spends even the smallest fraction of their life to give a gift to the world does not deserve anything but praise from those who benefit from it.

type0 8y ago
> Despite all this, I have open sourced a couple of things here and there. Little things. Things that virtually no one ever used, as far as I know. You wouldn't know, when learning every help and every practical example can be useful. I understand that not everyone likes to learn by reading someones code but it can be invaluable especially for students in places where books are prohibitively expensive compared to the living standards. You're doing good deed, even if it's just small things, but make sure to document it properly.

ngcc_hk 8y ago

A free gift like fire to mankind can be both great if useful and bad if misused. Just nature. And the being helped it forever have an eagle chasing his liver ... or he has to do the stone.

classichasclass 8y ago

I have a rule I don't maintain software I don't personally use. It's kept me from picking up projects other people ask me to do for them, and it's been a good dividing line when it's time to hang it up. I think his major mistake wasn't advertising he'd moved on, and I feel badly for the heat he's taking.

davej 8y ago

Personal attacks are completely unwarranted. I think a more useful (and certainly more constructive) way to look at this is to frame it as a learning experience and figure out what we can do to minimize the effect of this in future. It's almost impossible to vet every sub-sub dependency of a large codebase without dedicating huge resources. Perhaps there needs to some sort of a javascript code signing standard that requires a level of user identity verification. This is a solved problem with Authenticode and Gatekeeper for executables on Windows/Mac. We have been able to hide behind the fact that we're devs (we know what we're doing!!), but many consumer-level applications (mainly Electron-based) now run node modules with user-level (or higher) permissions. Maybe we need to become a bit more diligent in this area and look at less ad-hoc ways of managing dependencies and identity verification.

bit_logic 8y ago

The community discussion is focused on the wrong thing. Here is the problem: https://github.com/dominictarr/event-stream https://github.com/dominictarr/event-stream Look at that URL. It has "dominictarr" in it. Now click on the URL. Look at the big "dominictarr/event-stream" in the upper left of the screen. Many are going to conclude that this package belongs to dominictarr. Almost everything in the UI indicates this. Developers don't trust code, they trust people and organizations. NPM and Github needs to make it very clear when ownership has changed. And needs defaults that properly inform all users when ownership has changed. For example, when I SSH into a server the first time, it asks if I trust the key. Then one day, what if it asks again? Then I can stop and investigate why the key has changed, what's going on, and if I should trust it again. With the current NPM/Github there's no warning to users. A developer could've checked dominictarr's background and decide they are trustworthy, which would then extend to event-stream as well. But where's the warning to users when ownership of event-stream has changed and they need to re-evaluate whether to trust the new owner? And why does it look like the project still belongs to dominictarr when it actually doesn't? Those are the key issues here.

trickstra 8y ago
> Developers don't trust code, they trust people well the code doesn't write itself, so partially true. But ultimately it's about accountability. If Dominic himself added the backdoor, his presence in the community would end that day. If an anonymous alias does that, we don't even know who to blame. Dominic's fault is not the backdoor, but the irresponsibility of handing over a used package to an anonymous alias. Not being clear about the fact that the package is abandoned. I wouldn't depend on an abandoned package, if I knew that.
- QuantumGood 8y ago
  > Not being clear about the fact that the package is abandoned This is really the key point here.
always_good 8y ago
The NPM organization could go much further to make these attacks harder. You pitch a really good one: Any time you npm update/install, display ownership changes (especially compared to your prev version). Another one is to show the source code on the NPM website itself instead of hiding it in a tarball. NPM basically trains people to assume the published code == the code at the linked repository. It's a hacky honor system that only helps attackers.

matte_black 8y ago

So much good software out there is forever hidden from the world because the creators are afraid to be seen failing publicly, because of shit like this. To the brave souls who release open source packages, here’s to you.

danso 8y ago

I agree that the author has every right to quit being a maintainer, for any reason, but I don't believe that he is necessarily absolved of all judgment just because it was a free project he did on his own time. He's obviously a prolific and generous author, but that experience also means he's very aware about real-world practices (especially in the npm ecosystem) to know that ceding control of a popular library, without taking any precaution, has the potential to put a significant number of users at risk. Should the users be less complacent? Sure, but that's not currently the world we live in, and the author is not ignorant of that. If an experienced electrician volunteers his time to a homeless shelter, and decides to quit halfway through a rewiring project, it's his right to quit whenever. But the manner in which he leaves the project is also important. There's a huge difference between: - Confronting the shelter manager and saying "Hey, I can't do this anymore, and you get a professional ASAP to fix my work because I can't guarantee that I've properly grounded everything" - Exchanging pleasant goodbyes with the shelter staff, and not giving them any reason to worry about what you may or may not have done. The latter situation is akin to a silent failure -- even stomping off the job and telling the shelter to go fuck themselves is ultimately preferable, since the shelter staff at least are very aware that your work may be dangerously unfinished. While you may not be liable if anyone gets shocked/electrocuted from your leftover work, that doesn't mean the shelter staff are obligated to not grumble and warn anyone else who might be relying on you for volunteer work. edit: that said, I don't have a major objection to the author's response, as submitted here. I was referring to people who think that any significant criticism is unwarranted, just because the work is free. The author, to his credit, made a decently detailed reply and continues to make thoughtful responses.

mehrdadn 8y ago
I think your example makes your point weaker rather than stronger, because unlike the electrician, this guy has no reason to believe he's done a bad by job himself, because he's not putting anyone's life in danger, and because others who are using his work are also supposed to be similar professionals in their technical fields and taking similar responsibility. Comparing it to laymen who know potentially nothing about secure wiring getting potentially electrocuted because of a malpracticing electrician is not a great comparison.

brians 8y ago

And this is why professionals didn’t depend on build-time fetch of dependencies.

Domenic_S 8y ago

> There are too many NPM packages, and worse, too many people quick to add as many dependencies as possible, resulting in crazy dependency trees that you should never actually see in the wild. Additionally, it seems to only be in the node ecosystem that you see single authors with hundreds of packages. Why they do this, I do not know... Because javascript has a weak standard library.

PhilWright 8y ago
Maybe the most popular small libraries should be merged together into a single library that can be used to reduce the number of dependencies, in the hope it can become a standard. Like a jQuery for npm.
- kangax 8y ago
  I think that was the motivation of https://js.foundation https://js.foundation
zaphar 8y ago
Nah it's less about the standard library and more about the fact that Javascript doesn't have dead code removal so keeping a package small is one way to ensure you aren't pulling in code you aren't going to use. Of course the failure mode here is that you if you still choose a batteries included framework. (i.e. Angular, or a React powered framework) you end up pulling in a whole bunch of code you don't use and the list of dependencies is unmanageable. But because javascript was born in the browser and most javascript still has to be shipped to a browser it has constraints most other languages do not.

nkkollaw 8y ago

I read this: https://github.com/dominictarr/event-stream/issues/116#issuecomment-440927400 https://github.com/dominictarr/event-stream/issues/116#issue..., which might seem controversial, but what was he supposed to do? I guess just let it rot and tell people to fork.

notacoward 8y ago

So much for "many eyes make all bugs shallow" I guess. Problem is that 99% of those eyes are turned only toward using the product of someone else's good will for their own personal profit. And 99% of the remainder are only looking for bugs in the features they use, or just aren't that good at spotting bugs. This only gets worse in environments like NPM, which make it easy for dependencies to proliferate beyond anyone's expectations, so people don't even know what code they should be looking at. This is still better than the situation with proprietary software, but problems like these are kind of inevitable in an ecosystem where people typically write 5% of the code themselves and blindly pull in the other 95% from who knows where via unchecked package dependencies.

wtracy 8y ago
Those "many eyes" are the reason this was caught at all. I could easily imagine situations where this backdoor would go unnoticed for months or years.
- notacoward 8y ago
  Some tiny subset of those many eyes might have found it, but by then its impact was far from shallow. In some open-source ecosystems (e.g. GNU or BSD) the ratio of useful eyeballs to vulnerable ones is much higher. It almost seems to be a goal of NPM to maximize the blast radius before a problem is noticed. That's not a healthy way to manage open-source projects.

kylecordes 8y ago

I have observed an ongoing pattern. People who create a thing (that becomes somewhat popular) in some sense get credit for it. They are mentioned as the creator of it, forever. It becomes part of their resume, their online reputation. Perhaps they go on to create another thing. This happens to a far lesser extent for people who adopt a project later to become an ongoing maintainer. A project might have an originator who works hard for six months, and rewarded forever, and some maintainers who work hard for six years and gets very little reward. Out of respect for many people who do great work, I will not name names. :-)

purplezooey 8y ago

Makes you wonder if we are at Peak Open Source

ralph84 8y ago
The largest pure-play open source company and the largest open source host both being acquired within the last 6 months is a strong indication.

flocial 8y ago

I don't know what it is about the current environment but it pains me to see people get the life sucked out of them for sharing code and making the world a better place. It's also equally disheartening to see prominent open source contributors essentially close their social media because they're constantly hounded by entitled "community" members and trolls.

raphlinus 8y ago

I think this is a major loss of innocence moment for open source. The only sustainable solution to this sort of problem is to pay people to do at least minimal curation and maintenance of open source libraries. In an ideal world, the payment would go to people who actually create open source value. However, I'm cynical enough about human nature and business to suspect that it will mostly go to middlemen like record distributors and academic publishers, who create very little actual value but somehow make themselves indispensable in the ecosystem.

udithishara 8y ago

> If I had realized they had a malicious intent I wouldn't have Welcome to the Internet There are people buying chrome extensions, so they could inject something else this guy is surprised when someone did it to his project, which he handed over for free

_nalply 8y ago

I found this comment insightful: https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a#gistcomment-2769564 https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36... Summary: 1. Mark as deprecated 2. Change the name by adding "-archived" 3. Turn off Github issues 4. Give away ownership if there is at least a mini-community

ship_it 8y ago
but noo, uh .. my fame!!! :'( cries in npm

carapace 8y ago

So NPM users et. al. are a hoard of unwashed children. This is like Lord of the Flies.

jeswin 8y ago

Dominic is a prolific contributor and compassionate leader in the JS and P2P communities - and it was a disheartening thread to read. The suggestions that he (working for free!) should have done more seemed unfair. We should look to fix these: - If we're going to rely on hundreds of packages per project, we need fine grained security like Android or iOS. deno seems to be doing node right - https://github.com/denoland/deno/issues/171 https://github.com/denoland/deno/issues/171 - Lock down versions for now. Use 1.2.1 instead of ~1.2.1 or ^1.2.1. - If npm must remain at the center of node's module system, they might have to add auditing and approval tools. 'npm install' can warn about unaudited modules. The problem with that is that it will make npm (a business) even more central to the node ecosystem - which may not be a good thing.

jahaja 8y ago

However you frame it, a very widely used package management system based essentially on trust and a community that doesn't expect any amount of responsibility with regards to those packages seems like a bad combination.

bytematic 8y ago

That was incredibly well written and I believe him truly. I had not considered that the amount of these tiny packages was probably people trying to learn.

mmgutz 8y ago

I dont get why the original author is getting so much flack. This is a problem with semver and npm. I hope versions are immutable on npm.

aequitas 8y ago
You could argue he could have done a better job in communicating he and his reputation is no longer what is behind this project. But that it has moved to someone else.

magma17 8y ago

the quid is if the maintainer is a douchbag or not

draw_down 8y ago

This whole debacle has really demented my thought that I would probably never maintain an open source project. There is so much downside.

randomsearch 8y ago

This is a little orthogonal, but I'd really appreciate thoughts on this: Is FOSS a good idea? I've always assumed yes. Think of all the libraries in the Python ecosystem, for example. I've used them to build tons of things, even a couple of things that made a little money and allowed me to get myself a new laptop. I've written open source projects myself, filed issues and helped fix bugs in others. The code I've written represents a lot of time, and I'm happy to give it away. Think about Linux, and what it has done for the world. I've used it for non-commercial purposes all over the place, and it's made research and teaching I've been involved in much easier; it may have been impossible to achieve many things without it. But recently I've begun to question the idea of FOSS, sparked by Jaron Lanier's concerns. There's something clean about paying someone for their software: you have an entity responsible for the code, you can pay for support, you have recourse if you need it. There are clear incentives and rewards, and money earned is properly redistributed. I know that companies like Google do a lot for FOSS, but it's probable that their contributions are minuscule compared to the monetary value they have extracted from it. The alternative is not closed-source: e.g. with web dev you can provide the source code but charge for licensing, etc. So it's more about "free" vs "non-free" than "open" vs "closed". The idea of people coding for free is quite an odd one. Imagine if the world's graphic designers en masse started providing millions of free designs covering every possible icon and situation? (I'm aware of small examples, but they're not at the scale of OSS). Designers don't do it. You would make a lot of people redundant overnight - not all designers, but a lot of them. What do people think? I can't see how we could have this amazing ecosystem without FOSS... but maybe some kind of transactional funding model is needed to make it sustainable, more secure, etc. My instincts were for FOSS, but there's often a difference between what sounds beautiful conceptually and the problems of how it works in practice. RMS' ideas were very attractive, but then you see the modern world from a musician's point of view and it sucks - the long-term effects of ignoring copyright have been to diminish income for musicians. Whilst I improve my friend's quality of life by giving them a copy of some music, their kids might grow up in a world with less good music as a result. I know the record industry sucked, but free copying is not the only alternative. I'd really appreciate input here, as I have failed to resolved this either way. Thoughts?

gumby 8y ago

Always makes me think of Brian Fox's canned response to people who flamed him about bash: "Please return your copy of bash for a full refund."

devxpy 8y ago

What happened to tidelift? https://tidelift.com/ https://tidelift.com/

ptx 8y ago

"Since the early days of node/npm, sharing commit access/publish rights, with other contributors was a widespread community practice. https://felixge.de/2013/03/11/the-pull-request-hack.html https://felixge.de/2013/03/11/the-pull-request-hack.html open source is driven by sharing! It's great!" Yes, but, quoting from his post he cites: "So should you really do this for all pull requests? Probably not. While I've given a large amount of users access to various projects of mine, I'm still looking for: "Github profile: Does this user stand to lose a reputation by doing something stupid? "Skill: Based on the patch, do I think the user could be a good developer? "Usefulness: Is this patch solving a valid problem?"