Instantly share code, notes, and snippets.

Embed
What would you like to do?
statement on event-stream compromise

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.

@broros

otherwise why would he hand over a popular package to a stranger?

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

One time, I was working as a dishwasher in a resturant, and I made the mistake of being too competent, and I got promoted to cook. This was only a 50 cents an hour pay rise, but massively more responsibility. It didn't really feel worth it. Writing a popular module like this is like that times a million, and the pay rise is zero.

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. 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 open source is driven by sharing! It's great! it worked really well before bitcoin got popular.

So right now, we are in a weird valley where you have a bunch of dependencies that are "maintained" by someone who's lost interest, or is even starting to burnout, and that they no longer use themselves. You can easily share the code, but no one wants to share the responsibility for maintaining that code. Like a module is like a piece of digital property, a right that can be transferred, but you don't get any benefit owning it, like being able to sell or rent it, however you still retain the responsibility.

I see two strong solutions to this problem...

  1. Pay the maintainers!! Only depend on modules that you know are definitely maintained!
  2. When you depend on something, you should take part in maintaining it.

Personally, I prefer the second, but the first probably has it's place. These arn't really mutually exclusive, anyway.

As to this particular issue, I have emailed npm support and suggested that they give the module to @FallingSnow and ar @XhmikosR

@dominictarr

This comment has been minimized.

Owner

dominictarr commented Nov 26, 2018

note: published here because of "cannot post at this time" errors on the original thread.

@joshmanders

This comment has been minimized.

joshmanders commented Nov 26, 2018

Well said, @dominictarr. This is not a problem with Node. This is not a problem with npm, this is not a problem with you. This is a problem with people being put in a state of responsibility for something they didn't ask to be put in a state of responsibility for.

You wrote code because you wanted to and gave it away free. Someone else decided to depend on that code, which in return got depended on by someone else, next thing you know you're little package is being used by 2/3rds of the internet.. And you're somehow required to give 100% SLA to people who use that code, because they decided to build a business that depends on that code and feel they aren't responsible for paying for it, because IT'S OPEN SOURCE!!!

@ArneBab

This comment has been minimized.

ArneBab commented Nov 26, 2018

If only someone had warned us that free software is not about price but about Freedom … someone who started copyleft free software by getting paid to create it … https://www.gnu.org/philosophy/selling.en.html

Calling it open source obviously did not help with getting maintainers paid, so maybe it’s time to revisit the use of the term "open source" on NPM, too, and call it free software again. And ask people for donations, subscriptions and patronage to help keep the software they use and need free. And if the original author does not want to do it, let companies step up and offer paid maintenance.

If only we had a way to distribute packages with maintenance by third parties. Something like distributions. That accept donations.

@togakangaroo

This comment has been minimized.

togakangaroo commented Nov 26, 2018

An idea I posted in a few places:

This is all coming from the point of view that the problem with large dependency chains is trust - trust that all those hundreds of projects in that massive chain have maintainers with good controls to prevent abuse. One way to add to trust would be to have multiple maintainers - if a project has 3 or 4 maintainers, they're less likely to have such issues.

So. Why not an Open Source Maintainer "Dating App"? Where you match people and their projects to facilitate "OSS rings/guilds/whatever". Where groups of people all cumulatively commit to maintain groups of projects?

Would make it easier to get started with OSS too, since you'd be guaranteed to be on a maintainer team, not just flying solo.

I've got two babies so...I'm not going to be kicking it off any time soon, but anyone else wants to start it up,I'd try and contribute.

@reqshark

This comment has been minimized.

reqshark commented Nov 26, 2018

owner(s)/authors of systems and running programs remain 100% responsible for their protocol mayhem

@sam0x17

This comment has been minimized.

sam0x17 commented Nov 26, 2018

I respect the author and his predicament. My thoughts below more reflect what I see as a problem in the js community in general.

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, but in other similar ecosystems something like this wouldn't be nearly as big a deal. You don't see this happening in pip, you don't see this happening in ruby gems. It used to be that people would spend months planning and contemplating whether to upload something as a publicly accessible package, and then they would maintain it for ~5 years at least. Now it is done in minutes on a whim and immediately forgotten. While nice in some ways, prolific authorship is causing huge problems for the js community. There are plenty of js people in my feed who create 1-2 open source packages a week. A week!!!!! The result is that the average quality of packages in npm is quite low, the average package is super umaintained. Why can't people just stick to making 4-5 packages for their entire lifetime, like they do in other ecosystems?

All of that said, if it really does take a million dependencies to do anything useful in js (and I don't think it actually does), maybe we need to fix the js/node ecosystem or the language itself.

@dominictarr

This comment has been minimized.

Owner

dominictarr commented Nov 26, 2018

I disagree that there are too many npm modules. If anything there are not enough modules! I am still having new ideas that require modules, or solving particular problems that can be well-stated and solved. Also, many people are learning to code, and sharing your work is a great part of that. I think sharing is good, and there should be more sharing, but that our ability to share has room for improvement - for example, we need to be better at sharing the responsibility to maintain.

@shellscape

This comment has been minimized.

shellscape commented Nov 26, 2018

I understand and sympathize with all of the sentiments expressed in the OP. I really, really do. However, I'd really like someone (or some people) to school me on a question haunting this entire situation:

Given how easy it is to view a person's Github contributions, activities, and associations, an individuals various other social media profiles, and often other bodies of work; why was there no five-minute, basic due diligence performed before handing over the project?

In so many ways this situation is an abject lesson. Many other users on the associated issue, and on the web in various places, have pointed out that there were red flags galore with regard to the bad actor. I haven't seen a direct answer to that question yet - only deflections. And yet it's one of the most important questions surrounding the situation.

@pmart123

This comment has been minimized.

pmart123 commented Nov 26, 2018

To be honest, if people or companies want @dominictarr to maintain his work, the best and the easiest way is to pay him. Hire him, sponsor the package, or offer up some of your developers' time if you are a company. If you are not spending any money or your own time to maintain a package, you should be grateful for any support offered.

@josmardias

This comment has been minimized.

josmardias commented Nov 27, 2018

I don't think the problem is too many modules or how a maintainer should or shouldn't behave.
The problem is that the platform has irrestricted access to the host machine, no sandbox, no lockdown.
We need to install modules without worrying.
It's a lot better to invest time trying to give the right permissions so a project can run, instead of wasting time auditing a gazilion modules.

@mklauber

This comment has been minimized.

mklauber commented Nov 27, 2018

@sam0x17 @dominictarr I think that node/npm are in a unique place with regards to modules. Most languages are not constrained by module size, since most languages/programs are not run "over the wire". Node is uniquely positioned where the cost of including an extra function is not O(1) but O(n). And it's not just the extra bandwidth, but the effects on download time as well. So, I think that npm has very reasonably moved in the direction of 10 small modules rather than 1 large one, but that brings additional costs in terms of maintenance, as this situation has demonstrated.

@kylecordes

This comment has been minimized.

kylecordes commented Nov 27, 2018

It would be fantastic if there was a way to pay (or even require to pay) some modicum of money for dependencies at the top level; have part of that money flow downward, like a pyramid scheme, to transitive dependency authors. Obviously this could bring on many of its own issues - but it would fix this problem of "create an important thing, everyone expects everything of you, for zero reward".

On the other hand, a price of even one cent, versus zero, would greatly change the dynamics and discourage the staggering proliferation of direct and transitive dependencies that we see across popular platforms. There are so many things in NPM, for example, that could instead be in some kind of blessed audited standard library - if there was a force pushing that direction.

@lagovens

This comment has been minimized.

lagovens commented Nov 27, 2018

@joshmanders

This is a problem with people being put in a state of responsibility for something they didn't ask to be put in a state of responsibility for.

oh, gee, I wish there was something the poor responsible authors could do to get rid of that unwanted responsibility... like... I don't know... MARKING THE PACKAGE ABANDONED???

@reqshark

This comment has been minimized.

reqshark commented Nov 27, 2018

red flags galore with regard to the bad actor

bad actors are a dime a dozen, who cares

when a prolific open source module creator stops maintaining something that's our number 1 red flag

their generosity and abundance is a tremendous source of knowledge and insight so let's take full advantage of that focusing instead on the code, and not try to get all judge-y on newcomers indicating their willingness to try and help maintain the given away code.

Don't expect prolific creators to be any good at vetting social media spam or anything else unrelated about an interested and willing newcomer's lifestyle. Or judging other things distant from the aesthetic (the code). that's asking for a complete waste of their talent

so my red-flag total count is 1, eh maybe 2:

  • giving code away is a red-flag about the code
  • relying on code passed on from a prolific maintainer followed by complete lack of sharing in the new responsibility to maintain
@bstempi

This comment has been minimized.

bstempi commented Nov 27, 2018

I too have packages that I no longer maintain. They're still out there. The source is still there for people to fork and rename if they wish. What I didn't do was leave my name on it and hand it off the community to some untrusted stranger. You didn't just hand off a package; you handed off a community of users. As someone who has "security" listed as the first bullet point on their professional website, you ought to know better.

Simply abandoning the package would have done zero harm. By simply leaving your source there your gift was already "given away." Instead, you did something that was a poor security practice at best and shady at worst. Looking at your credentials I believe that you full well understand what you did. Even if you don't, this whole, "I'm not responsible for anything" is causing a Streisand effect. At the very least, an apology to the community and a reinforcement of why others shouldn't do what you've done is in order.

TL;DR: If you're bored or too busy, then just fucking abandon the thing. What you did was simply fucked up.

@diegochavez

This comment has been minimized.

diegochavez commented Nov 27, 2018

Man what a terrible situation, I saw many open source maintainers asking for help on projects, but a just a few raise the hand to help, it's sad.
Everyone wants to eat good apples, but nobody put a bit of water on the tree. The "JavaScript community" needs to be a community.

@thosakwe

This comment has been minimized.

thosakwe commented Nov 27, 2018

Man what a terrible situation, I saw many open source maintainers asking for help on projects, but a just a few raise the hand to help, it's sad.

This, times 1000.

@cryptogoth

This comment has been minimized.

cryptogoth commented Nov 27, 2018

I agree that this is a systemic incentive problem that would be good to solve with meta-open-source systems.
I'd like to both reward maintainers, who might otherwise keep working on their packages or choose a successor from a community of contributors / users, as well as disincent bad actors.

Some ideas:
An access-controlled, audited open source repository where some metric of usefulness, like number of downloads, gets proportionally distributed to maintainers, and also packages can be marked as unmaintained as of a certain version. Downloaders may pay to access the audited repository or contribute work to do the auditing / vote on trustworthiness of each update. If npm is not already immutable, have immutable releases so that vulnerabilities can't be injected into past releases.

For disincenting bad actors, reputations for package maintainers would help us evaluate whether a developer is a worthy successor or a fake account that wants to inject a vulnerability with impunity.

@warrenrumak

This comment has been minimized.

warrenrumak commented Nov 27, 2018

TL;DR: If you're bored or too busy, then just fucking abandon the thing. What you did was simply fucked up.

Two things:

  1. Dominic did something that's been done many, many times in the history of Github projects -- handed it over to someone else. You never hear about it most of the time, because it's uncontroversial and it usually works out great. This time it didn't work out. This reflects how things are in life generally; most of the time, people are good... and occasionally, people are dicks. Which leads me to the second thing:
  2. Don't be a dick, Brian. If you're feeling the burn to get angry at someone, be useful & direct it towards the Actually Bad people who write intentionally harmful software.
@balupton

This comment has been minimized.

balupton commented Nov 27, 2018

One time, I was working as a dishwasher in a resturant, and I made the mistake of being too competent, and I got promoted to cook. This was only a 50 cents an hour pay rise, but massively more responsibility. It didn't really feel worth it. Writing a popular module like this is like that times a million, and the pay rise is zero.

Why every open-sourcer should first read https://www.goodreads.com/book/show/662.Atlas_Shrugged


I see two strong solutions to this problem…

  1. Pay the maintainers!! Only depend on modules that you know are definitely maintained!

Despite the Bevry community having donation badges in all our READMEs:

Patreon donate button
Flattr donate button
Liberapay donate button
Thanks App donate button
Boost Lab donate button
Buy Me A Coffee donate button
Open Collective donate button
crypto donate button
PayPal donate button
Wishlist browse button

And a specific donation section:

Sponsors

No sponsors yet! Will you be the first?

Patreon donate button
Flattr donate button
Liberapay donate button
Thanks App donate button
Boost Lab donate button
Buy Me A Coffee donate button
Open Collective donate button
crypto donate button
PayPal donate button
Wishlist browse button

Which is automatically maintained thanks to the automation from badges, projectz, and boundation.

Despite that, this still results in NO DONATIONS A MONTH.

It is also worth saying that my packages get over 130 million downloads a month on my personal account, and 23 million downloads a month on my automation account, yet I get paid nothing, despite most of the packages now only being maintained for others benefits, no longer my own.

I'm considering adding a new badge to repos with their business model, with bevry using maintenance: bounties going forward and posting the following on every issue:

I am currently preoccupied with tasks that have revenue potential as my finances have depleted, so FOSS issues have been pushed to the backburner. If you want to speed them up on my queue, then consider making them a paid task by posting a bounty, as currently I earn nothing from my open-source work, so it cannot be a priority. Details for posting a bounty on this issue to incentivise its accomplishment sooner can be found here: https://discuss.bevry.me/t/bounty-donation-services/272?u=balupton

I did envision sponsored to solve this issue to provide more incentive to potential sponsors, however guess what, I ran out of funds for that too and priorities were brought back to non-digital life. Not everyone gets lucky with the open-source celebrity that many europeans and USA open-sourcers are gifted with.

For DocPad, a project that refuses to die, yet hasn't had any sizeable donations since 2014, which still gets support requests, I'm considering including a coinhive monero miner in its result output (completely obvious to the user via CLI messages) unless they buy a serial number for $20. This way people get access to it for free in exchange for CPU power while they are using DocPad, otherwise they can purchase a license.

I think the power of the coinhive monero miner has a lot of benefits. Salon recently adopted it as an alternative to advertisements.

For more direct dependencies, I think a platform could be made where a Mine for Open-Source app is downloaded, and consumers can opt in, or hopefully opt-out as evidently no one contributes to what they can get for free. For install of a package that opted into the "Mine for Open-Source" program/protocol, the miner operates for 2 minutes with that package's mining token. This allows open-source to be distributed for free, and allows payback to maintainers that increases for usage. Then users could donate directly to packages via the app if they still don't want to pay off their consumption debt for free via mining.


regarding automatic tooling around preventing npm publishes without automation, see our https://github.com/bevry/awesome-travis and https://github.com/bevry/boundation tooling, for us only a passed tagged build on travis-ci can deploy, as only that has the npm token for the automated bevryme account. So users are forced to push git tags to do releases. This could be enhanced by making use of a security scanner check as part of the continuous integration solution, so the package is only published if the tests pass and the security check passes.

@timwis

This comment has been minimized.

timwis commented Nov 27, 2018

This is a hard problem to solve... Perhaps requiring all pushes to master be approved by another maintainer could be a solution?

@rvagg

This comment has been minimized.

rvagg commented Nov 27, 2018

Here's some of my "solutions" after finding myself in a similar bind.

  • Mark packages in npm as deprecated with a polite message. It's not like npm isn't full of alternatives and many packages we publish there are not exactly rocket surgery—authors ought not fall into the trap of believing that their contributions to the world are so unique that they have to be maintained for the good of humanity.
  • "Archive" on GitHub and rename the repo to have a -archived suffix. GitHub will redirect and archiving sends a fairly strong message while not memory-holing it (if an author does use the memory hole, you probably should be concerned about their general stability).
  • Turn off Issues in GitHub! I'll be friendly if you come asking questions, but you don't pay me to be tech support. Only my direct family and my mother in-law get that privilege from me. If you can't figure my project out, maybe you shouldn't be using it. If it's failing for you, fix it and submit a pull request. That's how open source should work. While GitHub has been great for open source "community" it's also reinforced the consumer transactional nature of the relationship. It's so low cost to open an issue, or add to a thread. But the burden to maintainers can be huge! Turn off them issues and stop doing other developers' work free of charge. Send that stuff to Stackoverflow where there are people who thrive on giving out assistance.
  • Give projects away or liberally share ownership—when you have a community you can trust—which is a reason to invest in mini communities that form around the open source areas you participate in. Of course you can't be oblivious to the trust that downstream users put in you when they made your code integral to their projects, but it shouldn't be the primary concern for the individual open source developer (there lies mental health problems).

My list of projects that I actively "maintain" has gone from over 100 to a handful that I can manage and enjoy.

npm users are pretty lazy when it comes to understanding their dependency tree. We've had a very good run where trust and goodwill have been plentiful. Giving npm users reason to look a bit deeper and look for alternatives when there are quality or stability concerns is probably going to be a healthy thing.

It's also worth noting that this is going on and may be looking at the problem of "too big to fail" packages: https://github.com/nodejs/package-maintenance

@sgeisler

This comment has been minimized.

sgeisler commented Nov 27, 2018

Since the early days of node/npm, sharing commit access/publish rights, with other contributors was a widespread community practice. [...] open source is driven by sharing! It's great! it worked really well before bitcoin got popular.

Bitcoin didn't change the incentives much here, it just made them more apparent to the wider public. Before bitcoin possible reasons for injecting malicious code into popular packages were:

  • identity theft
  • DDoS attacks
  • ransomware (iirc that's nothing new)
  • stealing company/state secrets
  • lulz
  • ...

At most crypto currencies act as a lightning rod by being a hugely profitable target. The nice thing is it forces the attackers to reveal their presence in order to take their profit (other than e.g. machines used for DDoS attacks that can stay undetected for a long time). This incident is a valuable lesson for many people (me included) that might have been less concerned about the trust they put in their dependencies before.

@dominictarr

This comment has been minimized.

Owner

dominictarr commented Nov 27, 2018

@bstempi

Simply abandoning the package would have done zero harm. By simply leaving your source there your gift was already "given away." Instead, you did something that was a poor security practice at best and shady at worst. Looking at your credentials I believe that you full well understand what you did. Even if you don't, this whole, "I'm not responsible for anything" is causing a Streisand effect. At the very least, an apology to the community and a reinforcement of why others shouldn't do what you've done is in order.

TL;DR: If you're bored or too busy, then just fucking abandon the thing. What you did was simply fucked up.

As it happened, I was coming around to this decision. A while after giving event-stream away, I shifted 343 modules to an account that I no longer control - so that I can more easily say "no, I can't help, I cannot publish that module anymore". I had been intending to archive them on npm, but neither npm or github have tools to do things like this in bulk, and I had hundreds of modules to disown. I was gonna write a script to do this, I just hadn't gotten around to it yet... At the time of disowning all these modules, I had already transferrered event-stream, and no malicious activity had been reported, so I just removed my self.

If you say that I should have recognized malicious intent - well, you are just scapegoating me. the hacker would have just moved on to the next module in their list, sooner or later someone would say yes.

@dominictarr

This comment has been minimized.

Owner

dominictarr commented Nov 27, 2018

btw, that account is: https://www.npmjs.com/~nopersonsmodules

@segeiser my understanding is that the vast majority of actual malicious code that has wound up on npm has been cryptocurrency related. so while there are other reasons for attackers, none of them were really sufficiently compelling to motivate anyone to attack npm modules until recently.

@jackspaniel

This comment has been minimized.

jackspaniel commented Nov 27, 2018

Has anyone ever tried to put a bounty on fixing bugs/adding new features? Can someone just say "This project is abandoned, unless I get a certain amount from Patreon, then I'll do xyz"? The owner could even split the cost with a maintainer who wants to make a little $$.

Seems fair.

@alirobe

This comment has been minimized.

alirobe commented Nov 27, 2018

It sucks that this happened. Our systems should include allowances for people to be people, and failing that, we should allow for it.

This episode is unfortunately rife with systemic problems that are well understood, many have been outlined the creator of node.js: https://www.youtube.com/watch?v=M3BM9TB-8yA

A discussion on blame is neither useful nor productive. Doubtless there are people who are not blameless, but we should assume innocence unless we have proof of anything else... We shouldn't be relying on trust of individual package authors and publishers. We should be working towards trustworthy execution, so that even a malicious author (and they obviously do exist!) can't do this. There's no reason why someone writing a package like this should have been given the privilege on my system, except that node has too many privileges. One should not need to be an OS security expert to publish a simple javascript package. It is neither a sustainable nor realistic expectation, and even if it were reasonable, security experts are still human. Mistakes will be made, and systems should allow for it... failing that, we should allow for it.

@JerrySievert

This comment has been minimized.

JerrySievert commented Nov 27, 2018

sadly this goes well beyond the node ecosystem - I'm there myself on something that gets a ton of usage.

still not sure what to do with it.

let's grab beer next time you wander into town, maybe we can cry on each others shoulders.

@noscripter

This comment has been minimized.

noscripter commented Nov 27, 2018

Just my two cents, it's an honor and privilege to main a popular npm module. I'd say I can fully understand your feeling of maintaining such popular modules, I suggest the best way to solve this kind of situation is to create an organization for maintaining such related modules. But personally, I think this incident would compromise your reputation as an open source module maintainer which I sincerely feel sorry about and the effect of that may be irreversible.

Anyway, thank you for your contribution to the open source community, you're a hero and your pay is not zero, you receive respect and honor for your work as well as greater responsibilities.

@alirobe

This comment has been minimized.

alirobe commented Nov 27, 2018

Leaders of various communities have been attacking issues of trust in many ways, for a long time. Git/Github is one such attempt. Solid. Brave, Ethereum, Gitter, even Twitter/Medium, SyncThing - there are many attempts at different angles of the same problem. A large part of making progress is understanding that existing systems and outcomes are already complex. A lack of progress will result in bickering. Progress always results in frustration at a lack of further progress.

I think Github, node, and npm communities are all suffering from the stagnancy of being platforms that are depended upon to work a certain way. They do represent massive progress, but they are also stepping stones. We need to recognize that, understand that, and start to shift towards building momentum of progress at that level... even if it does mean discarding backwards compatibility (and I hope it doesn't!). I suspect the shift towards a distributed, self-funding, self-hosting cloud ecosystem is eventually inevitable, it may solve many of these problems, and it may come about sooner than we might imagine. But of course, we all need to work towards it.

Underneath all of this work, karma remains an incredible force in the world, and it shouldn't be underestimated... even if it's not calculable. Mistakes can be forgiven. Work can be appreciated, and life moves on.

@sartaj

This comment has been minimized.

sartaj commented Nov 27, 2018

Here's a 3rd suggestion:

  1. If you are dealing with sensitive data, have a zero-trust policy with OSS. Use strict CSPs, which can prevent data theft, and thorough tests, which can prevent compromised UX's.
@karlbecker

This comment has been minimized.

karlbecker commented Nov 27, 2018

Just a quick note that a company I recently learned about - https://www.tidelift.com/ - seems to be focused on addressing many of the problems mentioned in a variety of comments here.

No affiliation with them - I’m just interested in maintainers of widely-used packages to remain motivated, and for companies who want some guarantees about a package to pony up some money, which also benefits the community at large since more free software is well-maintained.

@felixge

This comment has been minimized.

felixge commented Nov 27, 2018

@dominictarr I'm sorry this happened to one of your modules. Ignore the negative comments. I've given away access of modules to largely unvetted 3rd parties myself and have just gotten lucky to not end up in a situation like this. But this is absolutely not your fault. People need to understand that the "no warranty" part of the MIT license means exactly what it says. If that's not good enough, write all the code yourself and/or carefully vet your dependencies. I understand that not everybody has the budget to do this, but that doesn't mean you should be the one providing that service to them for free 🤷‍♂️ .

@chr15m

This comment has been minimized.

@idangozlan

This comment has been minimized.

idangozlan commented Nov 27, 2018

It's a good time to remind that whitelist the outgoing traffic is super important and can prevent most of the data theft attacks.

@stuartellis

This comment has been minimized.

stuartellis commented Nov 27, 2018

I think that it's a core infrastructure problem. People should be able to experiment and give away code without obligation, but if a piece of functionality is so critical to an ecosystem that everybody needs it, then there needs to be organized, ongoing maintenance by a trusted group.

The usual solution is not great: teams developing programming languages almost inevitably end up maintaining an overgrown standard library, and wishing that they had not accepted maintainership of so many packages.

Perhaps JavaScript needs an Apache Commons: https://commons.apache.org/

@paulsapps

This comment has been minimized.

paulsapps commented Nov 27, 2018

The real issue here is something so core and popular used by tons of people but owned by 1 person.. what could go wrong ;). If someone is doing something in their spare time for free then IMO they owe you nothing.

@Stargateur

This comment has been minimized.

Stargateur commented Nov 27, 2018

There is nothing to say, the project have MIT licence No warranty is given period.

@lightster

This comment has been minimized.

lightster commented Nov 27, 2018

@dominictarr I just wanted to leave words of support. There’s a lot of negativity towards you that you don’t deserve. Keep experimenting, learning, and having fun.

@VladBozhinovski

This comment has been minimized.

VladBozhinovski commented Nov 27, 2018

Well this is not going well for NPM. This attack is an attack on the fabric of trust.

@mdamien

This comment has been minimized.

mdamien commented Nov 27, 2018

In the Python community, there is a community called @jazzband who takes care of long-term popular but stable packages: https://github.com/jazzband/ (also suggested by @stuartellis)

@yelouafi

This comment has been minimized.

yelouafi commented Nov 27, 2018

Something I don't understand in the above discussion: it's too focused on the social (vs technical) aspect. How paying/contributing would guarantee incidents like this won't happen again? being a paid maintainer doesn't make me immune to social engineering attacks. Sure, being paid I'll be spending more time on the project but a project has typically to be maintained by several persons, we're still relying on the vigilance of the maintainer to trust the right persons. I don't think this constitutes a reliable way to handle security issues.

Isn't it more appropriate to ask about a security sandbox model for Nodejs packages? I'm in no way expert on the subject, but seems like security in Node s more about treating "vulnerabilities" in package code against threats coming from the web side. But that presuppose the package code itself is trusted.

@benjamingr

This comment has been minimized.

benjamingr commented Nov 27, 2018

@dominictarr - thank you for working on this and I'm sorry this happened to you. I realize the backlash must be very frustrating.

I think we need to have a discussion (as an ecosystem) on how to address this problem.

@jotak

This comment has been minimized.

jotak commented Nov 27, 2018

That would be so much saner if everybody used fixed version dependencies instead of ~ or ^. Not removing the risks, but reducing the threat exposure.

@ghuntley

This comment has been minimized.

ghuntley commented Nov 27, 2018

https://m.youtube.com/watch?v=Mm_RuObpeGo

As software developers we often make use of open-source software (OSS) but do we ever think about all the man hours that go into developing and supporting the project. When OSS breaks, or we need a new features, we log an issue on gitHub and then sit back awaiting a response.
After a week of waiting we start complaining about how badly the project is run. The thing about OSS that's too often forgetten, it's AS-IS, no exceptions. Different projects may operate differently, with more or less people, with work being prioritised differently, on differing release schedules but in all cases the software delivered is as-is, meaning that there is absolutely no SLA. In this talk we'll look at a day in the life of an OSS maintainer: what drives them, what annoys them and what keeps them up at night. Maintainers aren't jerks, they just care about the project more than you do.

@aschrijver

This comment has been minimized.

aschrijver commented Nov 27, 2018

It is also worth saying that my packages get over 130 million downloads a month on my personal account, and 23 million downloads a month on my automation account, yet I get paid nothing, despite most of the packages now only being maintained for others benefits, no longer my own.

As @balupton points out, the Donations model is not working all that well too (though with this issue, and similar ones ocurring in the future, companies and devs might be much more inclined to contribute to the stuff they depend on in their products).

It would be fantastic if there was a way to pay (or even require to pay) some modicum of money for dependencies at the top level; have part of that money flow downward, like a pyramid scheme, to transitive dependency authors.

And even if donation/payment schemes (e.g. like @kylecordes suggest above) would work, then it would not really solve the issue too. After all, even if the module developer is now earning money, she/he is still not required to give any level of support, or continue to be a maintainer. Or to transfer their repo and/or privileges to another maintainer who is willing to take over. There will be more interest to maintain a project, probably, but no assurances unless you change the licensing and/or add additional clauses/contracts.

So. Why not an Open Source Maintainer "Dating App"? Where you match people and their projects to facilitate "OSS rings/guilds/whatever". Where groups of people all cumulatively commit to maintain groups of projects?

Like @togakangaroo suggests, this would also help creating a more stable module ecosystem, and people like @rvagg can transfer their unmaintained (but popular) modules to them. Isn't this similar to how Apache and Eclipse foundations work? You would still get a lot of stuff that is archived, goes to the Attic. Problem here is that, if you want to have guarantees on support, quality and security etc. then these initiatives tend to get quite formal, with lotsa procedures and pomp and ceremony.

I guess too there is niche now for automated OSS dependency / risk analysis tools and crowdsourced audit / review databases on which they are based. Probably such tools already exist, I would gather.

@btakita

This comment has been minimized.

btakita commented Nov 27, 2018

Open Source is a great way to maintain control over IP across multiple projects.

Some mentioned that we need to rethink the node or npm ecosystems. Instead, we should rethink our reasons for open sourcing software.

An opensource monorepo is a great way to build a software stack that can be reused across multiple projects. I created ctx-core/ctx-core for this reason. Atm, the docs are sparse, but I know how to use it & it's a great way for me to utilize & improve the IP & techniques that I created across multiple projects.

This same idea could scale to teams as well. The benefit is to the users of the tech, which is first & foremost the programmers. If I'm the only user of this tech, I still benefit. I also benefit from spreading this idea, as it would encourage people to build monorepos & think about how to architect said monorepos.

@joepie91

This comment has been minimized.

joepie91 commented Nov 27, 2018

@btakita The primary reason of existence for open-source is to build a freely usable public commons. It's not about reuse for your own projects, even if it makes that easier, nor about "maintaining control over IP".

@shanna

This comment has been minimized.

shanna commented Nov 27, 2018

@jackspaniel

Has anyone ever tried to put a bounty on fixing bugs/adding new features? Can someone just say "This project is abandoned, unless I get a certain amount from Patreon, then I'll do xyz"? The owner could even split the cost with a maintainer who wants to make a little $$.

I have. Fundry (fundry.com) focused on crowd funding feature and bugs as bounties. You could describe it as a cross between Patreon and UserVoice though it pre-dates Patreon. We bootstrapped it with revenue from https://www.retailmenot.com but shut it down when the latter was acquired. Fundry gained a little traction early on but only a little.

The complete source is here if you want to poke around: https://github.com/stateless-systems/fundry

@voronoipotato

This comment has been minimized.

voronoipotato commented Nov 27, 2018

Next time agpl license your code I guess.

@billrichards

This comment has been minimized.

billrichards commented Nov 27, 2018

Mr Dishwasher: is there smthn that you recommend ppl should use instead of event-stream?
<3
Bill

@Xe

This comment has been minimized.

Xe commented Nov 27, 2018

I'm sorry you have to deal with such ungrateful people. You got played bro.

@DanielRuf

This comment has been minimized.

DanielRuf commented Nov 27, 2018

Great summary: https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a#gistcomment-2769551

And also interesting for me as contributor and maintainer.

PS, I think we should lock the issue 116 (the big one) as it is not helpful at the moment.
The "what happened" is clear, the "who is affected" mostly too and "what to do" too (pin / update / downgrade).

Let's work together to get all dependents updated and secure https://www.npmjs.com/package/event-stream?activeTab=dependents

@agraves

This comment has been minimized.

agraves commented Nov 27, 2018

@dominictarr

My dude

It's ok to not want to renew your lease. It's not ok to hand the keys to the first person who walks by on the street. If you want to write projects for funsies, you can easily do that on your own machine or share it with friends. By publishing it, you assumed a position of trust and certain obligations to the community whether you like it or not.

I hope this doesn't blunt your enthusiasm for writing and sharing open source, but it should disqualify you from maintaining open source projects that people use for work.

@ww9

This comment has been minimized.

ww9 commented Nov 27, 2018

Opportunity calls for the creation of a new a term. A specialization of the bus factor:

The dominictarr factor: A project controlled by only one individual has a higher chance of being donated to a random stranger with a malicious agenda.

@Riciardos

This comment has been minimized.

Riciardos commented Nov 27, 2018

@agraves if you decide to use an open source module with an MIT licence, all onus is on you to make sure it's working as intended and safe to use. Nobody is forcing you to pull it in, you can't just force obligations on people because you feel entitled to it.

@paulbrittain

This comment has been minimized.

paulbrittain commented Nov 27, 2018

So you messed up and facilitated the pwning of potentially hundreds of thousands to millions of people, you don't say sorry or show any remorse what-so-ever, you act totally defensive and then ask for donations?

ok

@agraves

This comment has been minimized.

agraves commented Nov 27, 2018

@Riciardos My hobby react project has a 6k line yarn.lock. Reading every update to every one of those dependencies to look for malicious contributors is physically impossible.

@agraves

This comment has been minimized.

agraves commented Nov 27, 2018

@shotlom If someone's "fun" gets malicious code in my production app then yes, I would love to "extinguish" that. OP should be able to publish any fun projects he likes on github but I'd support a year ban from him publishing to NPM.

@kdwinter

This comment has been minimized.

kdwinter commented Nov 27, 2018

@agraves Actually, I think even the license is quite clear about this:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The author owes you nothing by providing it for free. If you decide to make use of it, it is your own responsibility. Quit being so entitled.

@Stargateur

This comment has been minimized.

Stargateur commented Nov 27, 2018

@agraves It's not him who publish the malware version on NPM. Also, MIT license read it.

@paulbrittain Stop it right now, MIT license just read it. Why should he apologize he didn't promise anything, also he didn't ask for donation, he say that this projet was for fun and he didn't win anything with it so he consider that he don't have to support it in any way.

@Forevernowandgone Your comparaison is not valid. When you take the responsibility of moderate a forum, you take a responsibility, here again READ THE FUCKING MIT LICENSE.

ethical and moral responsibility and just legal responsibility

This is all your moral you impose here, legal law exist to avoid this. You can't judge with your rules. What is moral and ethical responsibility in this context ? nothing MIT License he already tell you, use this at your own risk. People who use this and then cry are pathetic.

@hodoulp

This comment has been minimized.

hodoulp commented Nov 27, 2018

The VFX world is facing the same kind of problem where original maintainer(s) of critical Open Source Project(s) moved to something else and/or stop maintaining the project (because of lost of interest, personal life constraints...). After years of discussion, the proposed 'solution' was to move these projects under the umbrella of an Open Source Foundation maintained & financed by 'big' players in the field.
The "Linux Foundation" is now helping the newly created "Academy Software Foundation" which is slowly (i.e. legal stuff is always slow) taking ownership of some of most critical Open Source Projects for the Film industry.

I do not know if it could apply to your domain. But it's still a potential answer to critical 'one hero' Open Source projects.

Everyone needs to have a life and have fun when doing something for free.

@bstempi

This comment has been minimized.

bstempi commented Nov 27, 2018

@dominictarr

If you say that I should have recognized malicious intent - well, you are just scapegoating me. the hacker would have just moved on to the next module in their list, sooner or later someone would say yes.

I'm not saying that you should have recognized their intent as malicious. I'm saying that this was not someone you trusted nor was an active member in the community, so handing them a package that had a significant user community was irresponsible.

Given that behavior and attitude, why should the community as a whole trust your packages? You might just do the same thing again and then complain about being scapegoated. Yes, the hacker is wrong, but so are you.

@runvnc

This comment has been minimized.

runvnc commented Nov 27, 2018

My take on it is that the actual serious problem is one bad actor. Up until that point, we have people being inconvenienced by some possible responsibilities. But nothing prevents people from forking and fixing issues on their own. So that issue is just people having unrealistic expectations of people who give away software library code. Solution to that is: number one to be realistic about expectations, and number two, maybe have a workflow or website for recruiting more maintainers. By being realistic I mean, look we got a bunch of free code, it seems to mostly work, how nice of them. Let me not bother them if I can figure this out. Maybe we actually need a new rule or another bullet point on a license: if you want me to look at your bug report, fix an issue, or do anything, then you have to pay money. Otherwise I work on only things that I am interested in and have zero responsibility. That is the actual fair way it should work without needing to be stated (although it more or less is stated in the licenses already). And despite the fact that no one wants to pay, we have been doing fine. Because most of the packages actually do the main thing they need to do, and the edge cases can be handled by the people who actually have them in their own forks.

The reason we had an actual major problem is again one incident caused by one person acting maliciously. What we should do is punish that person. Make it very obvious that people who betray trust on this scale are criminals and suffer very serious consequences. For example, say a person in the US doesn't have health insurance and needs three or four surgeries, their financial life is completely ruined. They now owe $750,000 that they can never pay because they have a mortgage. They weren't malicious, they were just unlucky. What happens to the perpetrator here should be at least as bad.

Take the amount of money people spent dealing with this based on salary/hourly rate. Add it all up. Find the guy who did this in real life. Make a class action lawsuit. That is the number of millions of dollars that he has to spend the rest of his life paying back.

There are 730,000 modules and this happened one time.

@DanielRuf

This comment has been minimized.

DanielRuf commented Nov 27, 2018

The reason we had an actual major problem is again one incident caused by one person acting maliciously. What we should do is punish that person. Make it very obvious that people who betray trust on this scale are criminals and suffer very serious consequences. For example, say a person in the US doesn't have health insurance and needs three or four surgeries, their financial life is completely ruined. They now owe $750,000 that they can never pay because they have a mortgage. They weren't malicious, they were just unlucky. What happens to the perpetrator here should be at least as bad.

See MIT license.
Also it is up to us and we have to present a strategy and actions (hi there, GDPR).

@DanielRuf

This comment has been minimized.

DanielRuf commented Nov 27, 2018

There are 730,000 modules and this happened one time.

It happens much more often but many do / did not see what happened (the security working group tracks such cases and it was not the first "drama").

@danielbachhuber

This comment has been minimized.

danielbachhuber commented Nov 27, 2018

@dominictarr Just wanted to pop in and say I appreciate your past and future contributions to open source. I'm sorry you're bearing the brunt of this backlash, as it's a failing of the system and not your fault personally.

@runvnc

This comment has been minimized.

runvnc commented Nov 27, 2018

@DanielRuf that information should be public. Where can I find a list or details of those incidents? How many people were affected? What were the monetary damages caused, if any? What happened to the person who actually did it? Were there any criminal charges?

If this information is not available or there were no criminal or legal consequences, correcting that is the first action that should be taken.

@jimkang

This comment has been minimized.

jimkang commented Nov 27, 2018

otherwise why would he hand over a popular package to a stranger?

@dominictarr: If it's not fun anymore, you get literally nothing from maintaining a popular package.

I think you've missed another simple choice here: You can stop maintaining it, and just say you've stopped maintaining it, and the module will stay this way, take it or leave it. You don't have to hand it to anyone that asks.

I also have enjoyed your modules. But I do think this is a mistake that you can easily avoid next time.

@somedude43

This comment has been minimized.

somedude43 commented Nov 27, 2018

Wow, so many utter idiots on here! I guess it's true less people pay for something, more they complain.

I never knew starting a project ties you to it for life!

@Taywee

This comment has been minimized.

Taywee commented Nov 27, 2018

@somedude43 It doesn't tie you to it for life. Nobody sane is saying that he was obligated to donate his time to the project, just that he shouldn't have handed it to a stranger. Everybody keeps bringing up the MIT license like it makes a bad decision not bad. It doesn't. It makes the bad decision not illegal. Saying "you messed this up and did something irresponsible and careless, potentially hurting a lot of people" is not something that should be countered with "well, the license says that it wasn't illegal, so I'm not sorry".

Generally you should act in a way that tries to hurt few people. A software license doesn't preclude that. That said, nobody should be jumping on @dominictarr, because that's pointless. Just avoid his packages in the future, because they aren't necessarily trustworthy.

@Hansuuuuuuuuuu

This comment has been minimized.

Hansuuuuuuuuuu commented Nov 27, 2018

Sad, sad thread full of entitlement.
The absolute state of open source.

@himelnagrana

This comment has been minimized.

himelnagrana commented Nov 27, 2018

Best possible outcome from this incident has to be - some new industry practice for keeping alive all abandoned projectrs that are widely used. I personally like the idea suggested here by @hodoulp.

It will be a complete foolishness if we don't awake now - do something productive to avoid future disasters (keeping in mind this incident has a smaller target group than the total trust-affected people) - and keep playing blame-games. It will only show how naive we are still now.

I am ready to volunteer onto any of the "maintainer group who will formally maintain abandoned projects that are valuable to industry" (it's really another discussion if I have the capability/competence of doing so).

thanks to @dominictarr.

@Taywee

This comment has been minimized.

Taywee commented Nov 27, 2018

@Hansuuuuuuuuuu Nobody here feels entitled. We aren't entitled to his work, and we all know that. Nobody is suggesting that he work for free. In fact, most people are saying that he should have done absolutely nothing and just abandoned it. If you're going to accuse somebody of something, at least respond to what people are actually saying.

@tunnckoCore

This comment has been minimized.

tunnckoCore commented Nov 27, 2018

@dominictarr agree.

I was gonna write a script to do this, I just hadn't gotten around to it yet... At the time of disowning all these modules, I had already transferrered event-stream, and no malicious activity had been reported, so I just removed my self.

I already was working on that in last few days. I just need to publish it. It gets author name, new owners and list of packages (or all author ones, by default). With it you can npm owner add or npm owner rm, so it will work on your case or if someone wants to add some friend to all of his packages (my case).

@rvagg, marking package as deprecated is kinda interesting idea. Automatically deprecate all previous and any new versions, with message for sponsoring. They still will be able to use them, but while installing they will get flood spam of load with messages for sponsoring/paid support, so at least they will pay to someone, because will be tired of looking at them. The sad thing is that you cannot later remove the deprecations, so even if they pay you they will still get the spam messages, but.. all in all it's better, you will get some money.

@balupton's idea about CoinHive Monero mining is also quite interesting and good variant.

I mostly can say what @balupton said. I have hundreds of packages with around ~20 million downloads a month, and never get paid even a cent for them. I recently launched Patreon, but it will follow the same zero month as in @balupton's, mostly sure.

All of my packages have repos, are well tested, documented and stable. Their badges and builds status were absolutely green, for years, until 2017, when i gone through switching account names and Travis bugged. Most of them don't have issues nor pull requests, nor repos were touched for years, but that not fucking mean that they are unmaintained or unstable or broken, right? Right! If someone can argue that, okey, but not make any sense someone to be able to argue about that. And so, users, which are lead by "recent acctivity in repo, or last published version" are completely wrong. Try the fucking package first, if it's broken raise an issue - the owner, author, maintainer or another user will get to you; if you can fix it, raise fucking pull request and please mention ping the known author, because not always can get notifications about PRs. If it's working, donate 1$ and continue your life.

So. Because all of those problems, last few months I'm thinking how "open source" licenses are completely broken and not helping and not making any sense. And that's specifically more about the open source licenses that are "Open Source Initiative" approved, as define by Open Source Definition which sucks. That's why for the last year and so, I am working on license called "Protect Origin License" - yes, it may not be open source as OSI defined, but hell better than all of the current open source licenses. I strongly believe such things can fix the "non getting paid" problem. In short it allows you to do anything with the code, even selling larger works including it; unless you get paid for using your own modification then to use it you need to suggest the modifications to the orginal one, or publish your fork with the same license.

I also found the LicenseZero which is kinda okey and still not so, but can't use it because don't and can't have Stripe account.

@bstempi

At the very least, an apology to the community and a reinforcement of why others shouldn't do what you've done is in order.

No, definitely no. He (@dominictarr) does not need to apology to anyone for anything. You are the owner of your shit and you can do anything. Yes you may have community and that communiy deserve only a notification of your decision. Yea that may be rude or unethical or whatever (for some people), but you done the shit for free and released that shit with the fucking open source licenses that definitely not work, at least in JavaScript case; so anyone can fork and do whatever they want. Or at least, if they were familiar and specific package is so important to them, damn they only needed to open fucking issue to express that they want to maintain it. So no, no apology.

I'm always curios/thinking what will happen if you just die and your packages don't have (or not all) other owners? What? Please someone to answer me. Probably one will contact the npm support, but still. And what, @bstempi, you need to apology from the grave or what? To a community that don't appreciate you, even with a cent? Come on.

@sparr

This comment has been minimized.

sparr commented Nov 27, 2018

By publishing this module in the first place, you accepted responsibility for a modicum of caretaking for its future. Never touching it again would have been a more responsible decision than handing it over to a third party about whom you knew virtually nothing. The last time I asked to take over a dead open source project, the previous maintainer spent a couple of weeks "interviewing" me via email, looking at my github commit history, etc. If you can't do that, then you need to take a hands-off approach to your old modules.

@jeremyckahn

This comment has been minimized.

jeremyckahn commented Nov 27, 2018

Thank you for writing this and sharing it, @dominictarr! I completely agree with your points here.

OSS devs give work away with generally good intentions and no tangible compensation. There is no SLA for OSS. There is no guarantee of quality of service for unpaid labor. If you depend on and really care about something, pay for it or establish some sort of contract for support.

OSS is great because users own their own copy of the code. This enables them to fix their own problems — something you can't do with non-OSS. The fact that they choose not to is not the principle maintainer's problem so long as they are not compensated for their work.

@Taywee

This comment has been minimized.

Taywee commented Nov 27, 2018

I feel like there's a disconnect in this thread. We know this many things:

  • People should vet their dependencies and trust of code more carefully.
  • What he did isn't illegal and he shouldn't be held legally liable for it (due to the no warranty clause in the license)
  • He didn't want to maintain the project anymore and shouldn't be expected to.

But at least can we point at the specific action of giving complete ownership and publish rights of a widely-used library to a complete unvetted stranger and say that maybe we shouldn't do that in the future? I don't want to get into the dogpile thing, and I don't want anybody to be tarred and feathered for this, but it seems like lots of people here are saying that the decision made was actually a good one. I'm certain @dominictarr is a decent person, but we can at least judge this action as a mistake, can't we? Do we really think that everybody should act in whatever way pleases them with no regard for the safety of others as long as you are legally covered?

@planetmcd

This comment has been minimized.

planetmcd commented Nov 27, 2018

Correcting @balupton, no one should read Atlas Shrugged. Life on earth is time limited, don't waste time on a crappy book like that.

@joshmanders

This comment has been minimized.

joshmanders commented Nov 27, 2018

@lagovens

@joshmanders

This is a problem with people being put in a state of responsibility for something they didn't ask to be put in a state of responsibility for.

oh, gee, I wish there was something the poor responsible authors could do to get rid of that unwanted responsibility... like... I don't know... MARKING THE PACKAGE ABANDONED???

I see you created your account yesterday. I guess having a shit tier attitude towards maintainers is why you fear posting under your real account.

@paulkmiller

This comment has been minimized.

paulkmiller commented Nov 27, 2018

@lagovens

@joshmanders

This is a problem with people being put in a state of responsibility for something they didn't ask to be put in a state of responsibility for.

oh, gee, I wish there was something the poor responsible authors could do to get rid of that unwanted responsibility... like... I don't know... MARKING THE PACKAGE ABANDONED???

I see you created your account yesterday. I guess having a shit tier attitude towards maintainers is why you fear posting under your real account.

Oh my good lord, someone call the police, there's been a murder

@ryanwarsaw

This comment has been minimized.

ryanwarsaw commented Nov 27, 2018

@Taywee

I feel like there's a disconnect in this thread. We know this many things:

  • People should vet their dependencies and trust of code more carefully.
  • What he did isn't illegal and he shouldn't be held legally liable for it (due to the no warranty clause in the license)
  • He didn't want to maintain the project anymore and shouldn't be expected to.

But at least can we point at the specific action of giving complete ownership and publish rights of a widely-used library to a complete unvetted stranger and say that maybe we shouldn't do that in the future? I don't want to get into the dogpile thing, and I don't want anybody to be tarred and feathered for this, but it seems like lots of people here are saying that the decision made was actually a good one. I'm certain @dominictarr is a decent person, but we can at least judge this action as a mistake, can't we? Do we really think that everybody should act in whatever way pleases them with no regard for the safety of others as long as you are legally covered?

You could've very easily had a similar situation in which it wasn't an unvetted stranger, for whatever reason (account compromised, social engineering, etc). I think for me, the bigger takeaway here is we need to be more cognizant of what is in our development pipelines overall.

@eavalenzuela

This comment has been minimized.

eavalenzuela commented Nov 27, 2018

Or perhaps the real lesson is that if you're going to use FOSS in your production code, fork it yourself and work from that. It's absolutely unconscionable to put this on the original owner; this risk is not created by him handing the package off, it's created by including code in your production system that can be changed by anyone outside of your trusted processors list, including the original owner.

If @dominictarr been malicious from the start, he may have been more legally liable, but that wouldn't have changed the risk of what could have been done to your code; that risk was always there, but this incident is making people face the reality of having ignored it.

@Taywee

This comment has been minimized.

Taywee commented Nov 27, 2018

@ryanwarsaw
I agree entirely. The disconnect I don't get is how we turn "don't attack @dominictarr because it was an honest mistake" into "This wasn't a mistake at all and there is nothing wrong with carelessly enabling the widespread harm of lots of people as long as it's legal". I'm on board for the former. I'm definitely not on board for the latter.

@eavalenzuela

This comment has been minimized.

eavalenzuela commented Nov 27, 2018

@Taywee the only reason this project could "enable widespread harm of lots of people" is because those people pointed a loaded gun at themselves, and then handed it to @dominictarr. He didn't ask them to, and there wasn't even a need for them to, but it was easier and faster than not doing it, so everyone did.

Now you're complaining that the responsibility he didn't want, to prevent harm that he shouldn't have been able to inflict anyways, was on his head nonetheless...

@Taywee

This comment has been minimized.

Taywee commented Nov 27, 2018

Whether you asked for or want responsibility doesn't change whether you have it. If you have power that can be weaponized, you have a responsibility to ensure that it isn't used to harm people, whether you want it or not.

Those people were wrong, and they put themselves in harm's way, I agree. Them being wrong doesn't make his choice right. There also wasn't a need for him to give his rights to the first person who asked, and it was easier and faster than doing it the right way, so he did it. I don't understand why being lazy and getting yourself hurt is worse than being lazy and hurting others. I really do feel for @dominictarr, but I still feel that his decision was careless and wrong.

@eavalenzuela

This comment has been minimized.

eavalenzuela commented Nov 27, 2018

In the end, your own risk(in relation to code or otherwise) and the risk to your company and work is your responsibility. It is not anyone else's. It is 100% on you to manage your own risk, which people didn't do.

@anerdwithaknife

This comment has been minimized.

anerdwithaknife commented Nov 27, 2018

@agraves

Sounds more like you and the rest should be disqualified from using Open Source projects/code.

@dominictarr has not handed over the keys to anything compared to what you and your likeminded have done by blindly installing/upgrading npm packages into corporate environments with exactly zero auditing or security measures.

This isn't even a new concept or problem with npm, yet everyone has kept on marching to the pied piper regardless of incidents like Leftpad. Take responsibility for your code, twice so if you use someone else's and thrice so if you bring it into a sensitive environment such as a project that handles monetary transaction/logic such as Bitcoin.

@programatt

This comment has been minimized.

programatt commented Nov 27, 2018

npm users are pretty lazy when it comes to understanding their dependency tree. We've had a very good run where trust and goodwill have been plentiful. Giving npm users reason to look a bit deeper and look for alternatives when there are quality or stability concerns is probably going to be a healthy thing.

@rvagg Have you ever used create-react-app? You don't even do anything but npm install create-react-app and your node modules folder has almost 2k other packages in it. Even if I wanted to understand all the dependencies I'm screwed. It has to be some combination of people not accepting that dependencies are more than just free labor from someone else, and the issue of insane complexity in modern js projects.

@ZigMeowNyan

This comment has been minimized.

ZigMeowNyan commented Nov 27, 2018

I sympathize with not wanting to do work for free. Javascript package maintenance can add a ton to your workload. Your actions aren't innately problematic, but they show us a glaring hole in the javascript ecosystem - there's no established means of orphaning a package other than hoping someone will "take it off your hands" without ruining it. Which is how stuff like this happens. It also might have been better if you'd openly talked about your desire to hand it off, rather than agreeing with the first stranger in a van with candy.

The javascript community needs a collective maintenance community. Or at least a nominal owner when the package is only going to get bug fixes. There's hundreds of packages, and many of them don't need individual attention. It needs to be well-known, so that maintainers will hand their old packages off when they're done. And it should preferably be listed on major repository sites and promoted. Lots of javascript is commercialized already. And enough major companies have these packages in their dependencies that they'd be willing to contribute to prevent hostile actions through social engineering. Eventually it could grow into a sort of standard library.

It does mean people won't get bragging rights for their 800+ packages on Github. But you also won't get PRs and issues weekly.

@samjudge

This comment has been minimized.

samjudge commented Nov 28, 2018

The fact that there is some major drama with a major npm package every year or so makes me think the issue is systemic, and not really the author's fault. Or maybe its just because npm is so popular. I dunno - but this would never happen on any other platform.

@perpetualcrayon

This comment has been minimized.

perpetualcrayon commented Nov 28, 2018

I personally could care less who comes and goes from a project, but I think it's this sort of thing that could ruin open source. If you don't want to do it anymore, don't do it. But knowing that others rely on it, force them to fork and put a note in the README pointing to the new "official" repo. This way different projects that rely on your work don't all get surprised at once. Some will trust the next guy and some won't. The ones who do might get bitten. Ultimately you're not responsible, but it shows that you don't care about your own reputation. It will be hard to trust your open source code in the future I imagine. It may even reflect negatively on you as an individual to some. As far as how reckless you are with others' livelihoods. @dominictarr

@fendy3002

This comment has been minimized.

fendy3002 commented Nov 28, 2018

@samjudge

The fact that there is some major drama with a major npm package every year or so makes me think the issue is systemic, and not really the author's fault. Or maybe its just because npm is so popular. I dunno - but this would never happen on any other platform.

That's because node's official library is so minimum that minimal functionality need to rely on several packages that also depend on other packages, making it very easy to inject malicious code. Add with the intent to make nodejs code able to be run on javascript client (browser) only makes it worse.

Can't say with event-stream, but many essential package like is-number, uuid, del, moment and lodash need to be bundled into node or have a collaborative or trusted source to maintain that package (and depend to no one). And IMO it's necessary now to separate node code with javascript client node.

@chx

This comment has been minimized.

chx commented Nov 28, 2018

While I am not an JS/NPM contributor, I have contributed to Drupal, an open source project a ... lot. Drupal has struggled with contributed module quality ever since I joined in 2005. Truly there is nothing new under the sun. We haven't been attacked in this way -- yet? Who knows.

With due respect, @Forevernowandgone you couldn't be more wrong in blaming @dominictarr in any way or form. If his motivation is fun then that's what his motivation is. If he also shared his work, be grateful -- and that's where it ends. Those who decided to use his code are responsible for said decision.

@dmabamboo

This comment has been minimized.

dmabamboo commented Nov 28, 2018

I think that it's a core infrastructure problem. People should be able to experiment and give away code without obligation, but if a piece of functionality is so critical to an ecosystem that everybody needs it, then there needs to be organized, ongoing maintenance by a trusted group.

The usual solution is not great: teams developing programming languages almost inevitably end up maintaining an overgrown standard library, and wishing that they had not accepted maintainership of so many packages.

Perhaps JavaScript needs an Apache Commons: https://commons.apache.org/

Yes, this level of structure is required to have a healthy ecosystem that we can rely upon. A few organisations, commercial or not-for-profit (which could be sponsored by businesses that use their open source code or modules) could be formed.
Also as a developer you need to ask yourself whether a library should be used if there is no mature support model or a strong community behind it (rather than just a couple of individuals) because you're taking way too much risk without properly assessing the consequences to your business. It's a shame, though that if you take a more strict approach now you wouldn't even be able to have the most used frameworks and libraries because they all cary poorly supported modules as dependencies...

@lukaseder

This comment has been minimized.

lukaseder commented Nov 28, 2018

I see two strong solutions to this problem...

In Java land, a lot of these little utilities have moved to projects like Apache Commons or Google Guava, which are used by most clients now. It's really mad how the node ecosystem currently has completely unmaintainable third party dependency trees with tons of transitive dependencies. Anyone remember left pad?

If there were solid utility libraries that everyone uses and that are more trustable (e.g. because governed by the ASF), such a "fun" little library like yours would never become this popular, and thus never become such a risk.

@tsteuwer

This comment has been minimized.

tsteuwer commented Nov 28, 2018

@noscripter

Just my two cents, it's an honor and privilege to main a popular npm module. I'd say I can fully understand your feeling of maintaining such popular modules, I suggest the best way to solve this kind of situation is to create an organization for maintaining such related modules. But personally, I think this incident would compromise your reputation as an open source module maintainer which I sincerely feel sorry about and the effect of that may be irreversible.

Anyway, thank you for your contribution to the open source community, you're a hero and your pay is not zero, you receive respect and honor for your work as well as greater responsibilities.

I sincerely hope this is sarcasm. Respect and honor don't help you pay your mortgage, car, insurance or food. The fact is this guy used his own free time and his repo exploded helping thousands of other developers not have to write something themselves. I don't agree with what happened but pets be real. This kind of response is bullshit. I hate reading this every time something like this happens. Take your honor and respect and throw it out in the trash. Most developers don't make shit tons of money.

@hackhat

This comment has been minimized.

hackhat commented Nov 28, 2018

When you depend on something, you should take part in maintaining it.

How do you take part in maintaining1k projects? React, Redux, Webpack, React-router easily add 1k dependencies.

@MangoPieface

This comment has been minimized.

MangoPieface commented Nov 28, 2018

I think, unfortunately, you've just been the spearhead of a new(ish) attack vector. Rather than anyone piling on and blaming you, as the author, we need to start thinking about how to solve the problem. In some ways this is a malicious extension of this issue, which happened over 2 years ago https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

It feels like something here needs to be fixed, questions on how this is done and who does this are open ones that the community needs to solve together.

@margerum

This comment has been minimized.

margerum commented Nov 28, 2018

You make it sound like there was some incredible burden keeping the package in a read only state. You should have just let someone fork it.

@wsrast

This comment has been minimized.

wsrast commented Nov 28, 2018

It seems we have a need for a Foundation entity which would act as an end-of-life owner for abandoned packages. This would provide a central location for the vetting of charitable maintainers who would have a process to submit the transition of ownership from the original author(s) to the Foundation. I'm sure that once the process was established, some of it could even be automated to include things like warning messages in NPM during installations which would announce the abandoned package's status and who to contact at the Foundation for any issues that warrant further attention (catastrophic bugs, hacks, etc.).

I'm not sure what actor could sponsor such an organization, but this seems like a good idea to me.

@dannymcgee

This comment has been minimized.

dannymcgee commented Nov 28, 2018

All of that said, if it really does take a million dependencies to do anything useful in js (and I don't think it actually does), maybe we need to fix the js/node ecosystem or the language itself.

This, in my maybe naive opinion, is the root of the problem. The web is in an awkward growth spurt phase where we are trying to do enterprise-level software engineering with technology that was in no way designed for that purpose. The mile-long dependency trees and black hole node_modules directories are bridging that gap, for now, but I can't imagine that this is really a sustainable solution in the long term, because this type of attack is only going to get more popular.

And yet, as long as the "vanilla JavaScript" that our browsers actually parse and execute is so awkward and unwieldy for developers to work with, the npm ecosystem is not going to fall out of fashion. People have been arguing against frameworks for almost as long as they've existed, and no doubt those calls will be renewed and become more fervent in the wake of this SNAFU, but a cursory glance at any job posting website will demonstrate the futility of those efforts.

I've yet to see a compelling solution proposed to the fundamental contradiction here, of the web's appeal as a platform for complex applications vs. the technology's suitability for the purpose, but we're going to have to come up with one.

@reidelliott

This comment has been minimized.

reidelliott commented Nov 28, 2018

@dominictarr – This all sounds very frustrating for you to deal with such a backlash. ༼ つ ◕_◕ ༽つ

@PhilippLgh

This comment has been minimized.

PhilippLgh commented Nov 28, 2018

One solution would be to multi-sign modules. Just "signing" code would already be great actually :D
But imagine a new collaborator was added or a new author would take over, make a change, and sign with his certificate. Then the original author would check (or not) and countersign.
You can now actually have tooling that trusts "original author" because you are using his software for 7 years but detects a "new author's" signature without any trust. Add some security / threat model to the mix and let your module manager reject updates or alert you when this happens.
In this kind of situation developers could then targeted audit modules in question...
This would also have the advantage that CI could publish releases without the need to access your certificate dongle / hardware token.

@lulzmachine

This comment has been minimized.

lulzmachine commented Nov 28, 2018

Just a comment here. You say this:

Pay the maintainers!! Only depend on modules that you know are definitely maintained!
When you depend on something, you should take part in maintaining it.

I'm not saying I disagree with this. It's perfectly resonable. The thing that has seemed to cause this mess is that even if I choose carefully which maintainers I trust, I can't possibly know what they will trust 4 steps away.
The reason why Web-Of-Trust didn't really become a big thing is that trust doesn't transfer that easily.

Even if I trust nodemon, that doesn't mean I trust nodemon->x->y->z->a->b dependency. Maybe that's why the node ecosystem is so brittle; it's great reliance on small modules means that trust is delegated in an irresponsible way.

@aercolino

This comment has been minimized.

aercolino commented Nov 28, 2018

I think a problem is that npm updates are built with hotfix in mind. Dependencies are immediately updated. Instead, whatever the version bump, there should be a buffer between release and widespread use. Something based on time and community vetting, maybe. But something that is unavoidable would mean a lot.

@nirizr

This comment has been minimized.

nirizr commented Nov 28, 2018

One of the reasons you're not getting donations, in my opinion, to your packages with tens of millions in weekly downloads, is that the majority of them are not groundbreaking and/or sophisticated enough to warrant a donation. When the community is so used to use a package dependency instead of implementing a single function of a few lines of code (e.g. the left-pad fiasco), it feels keeping things simple doesn't get enough weight in (some) development efforts.
Instead of condensing on the valuable and meaningful packages, it appears the npm community strives to do the opposite - create as many similar, loosely maintained packages.

@eirslett

This comment has been minimized.

eirslett commented Nov 28, 2018

@fzammetti

This comment has been minimized.

fzammetti commented Nov 28, 2018

I see some people calling for an apology. I don't think that's in order. I have my own not positive feelings about what @dominictarr did, but I'd prefer we just learn from this rather than pointing fingers at someone who contributed when he didn't have to. Most developers never take that step so I'd prefer not to pile on one who did.

Speaking as someone who has created, maintained and, for all intents and purposes, abandoned F/OSS projects, it's a tough situation to be in. Hopefully every maintainer of every project does feel a sense of responsibility to the community they build, but on the other hand, we can't expect people to not walk away for various reasons (including, as some have pointed out: death). It's simply the nature of the game. But knowing that, you've got to do it responsibly (when possible).

Now, is that responsibility entirely on the single person maintaining the project? Effectively yes, but it probably shouldn't be - it should also be on the community I think. After all, many people seem to think a maintainer has a responsibility to the community (which I agree with), but doesn't the community also have some responsibility to the maintainer? Isn't that kind of one of the basic principles of OSS? I think so.

Given that, my suggestion would be the kind of model that Meetup.com uses for abandoned groups, with some additions/mods.

First, a maintainer clicks a button somewhere that says "I intend to abandon this project". At that point, a clock starts ticking. By the time it goes off, say maybe 90 days in the future, one of two things happens. The first possibility is someone steps up and says "I would like to take stewardship" (and the maintainer can nominate people if they already have someone lined up too). If more than one, that's fine too. At that point, verified members of the community begin to vote (one vote per account naturally, and the vote can be changed up until the clock stops). Whoever has the most at the end is the new maintainer. Simple as that! The expectation is that, in basic open-source fashion, more eyeballs will yield better results. Voters would be expected to do some vetting, in whatever way makes sense. They can comment and discuss, and those up for a vote can, of course, comment back, try and sell themselves in essence.

In short: it becomes an election process that the entire community of the project participates in.

The other possibility is nobody steps up (or, I suppose, nobody gets any votes). In that case, the answer is simple: the project is frozen at the point that "I'm outta here" button is clicked (and that would happen either way in fact, but just temporarily if someone is ultimately elected). It's still available for use, but no more commits, no more bug reports, no nothing. It is then marked abandoned, deprecated, whatever status makes sense (maybe a new one even) and that's that. You make sure it's abundantly obvious on the screen that this project is no longer maintained, big red flashing banner, whatever.

If someone comes along later and wants to take over, they go through the voting process as described but they then have to fork the project with a new name. Some links can be added from the original project to indicate "hey, switch to this if you want the maintained version", but the old continues to exist in its final state, no longer able to hurt anyone (aside from bit rot).

I would suggest that anyone interested in the project must sign up for a mailing list and those people will be automatically contacted when a maintainer says they intend to abandon a project. I suppose it could go out to a wider audience, all registered NPM users or something like that, but I'd think something more akin to a "hey, I'm interested in/use this project, lemme know if anything happens with it" kind of self-limiting list would be more appropriate.

As a corollary, I would also suggest, essentially, a "dead man's switch" applied to all packages that leads to the same election process. If the maintainer doesn't perform some action for, say, six months, then the process automatically kicks off. Well, first they get an automated "hey, you still good?" message, with maybe a week or two to reply to halt the process from beginning. If not, THEN it's election time!

I think, in my mind, something like this would be the best of all possibilities. Projects can still be abandoned, but now it's a much more transparent and planned for event, even in the case of unavoidable sudden departures. I'm sure it's not a perfect system, but to me, I think it makes a lot of sense to at least explore such a thing. It probably makes the most sense to be built right into the NPM infrastructure, but it really might not have to be (aside from the whole freezing the project aspect) because I can envision someone building this as a third-party service that ANY F/OSS project anywhere could then hook into. I wish I had the time to put into building it myself, but I don't. I'll regret it I make someone else a millionaire of course :) But, I'd rather put the suggestion out there and let it either die on the vine or let someone run with it for the benefit of all.

@vitali2y

This comment has been minimized.

vitali2y commented Nov 29, 2018

@dominictarr thank you for all your contribution!

@macfreek

This comment has been minimized.

macfreek commented Nov 29, 2018

@Forevernowandgone, I'm afraid I disagree with your statement:

If you write code and open source it, fine, leave it at that.

But becoming a maintainer of a package that is used by millions of projects puts some modicum of trust and responsibility on you. The two are completely different.

In light of what happened, It would probably be good if these two are completely different, but in fact, they're now exactly the same. The OP wrote code, and posted it on GitHub. From what I read, he did like to leave it at that. Case in point: the OP points to alternative libraries he wrote later that he deems 'better', it is implied that he rather saw those become popular.

You someone seem to assume that it possible for a community to bestow responsibility upon an open source author, even if the author is not willing to or unable to take that responsibility.

As for your argument that the author must mark the library as "archived", I think that's already implied: the author explicitly included a no-warranty statement, and you can see that it is not actively maintained. Relying on an active "archive" flag would fail for authors who are no longer able to modify, people move on or even pass away.

I agree that we need better indications of high-quality, well-maintained libraries. However, forcing non-active authors to tag their no-longer-of-interest projects does not seem like the most effective way to do that.

@dfraser-veea

This comment has been minimized.

dfraser-veea commented Nov 29, 2018

@macfreek Well stated all around. I have thumbed quickly through this thread and I was startled to see the assumptions that people make about "hey, you wrote this, now you must maintain it". For free. Forever. All responsibility and no reward.

Your final line speaks truth. I don't know what the solution is, but access tracking to the project has to provide some indicator.

Yes, we all want safe secure code, but telling people that they own lifetime responsibility just by the mere act of publishing is going to shove otherwise responsible people out. Most things I see on github are in the realm of 'here is a thing I did that I used for this purpose". Feel free to fork it and play around, but don't assume someone is going to 'own' it for your sake. If it is important to you, fork it, and take responsibility yourself.

@StephenLynx

This comment has been minimized.

StephenLynx commented Nov 29, 2018

protip: stop using too many libraries. That's the whole npm community problem. People have a dependency fetishism.

@StephenLynx

This comment has been minimized.

StephenLynx commented Nov 29, 2018

I don't think the problem is too many modules or how a maintainer should or shouldn't behave.
The problem is that the platform has irrestricted access to the host machine, no sandbox, no lockdown.
We need to install modules without worrying.
It's a lot better to invest time trying to give the right permissions so a project can run, instead of wasting time auditing a gazilion modules.

Servers are not smartphones. It's an utter waste of time doing either. People are just using the tools they have in a irresponsible way.

@eckerdj7

This comment has been minimized.

eckerdj7 commented Nov 29, 2018

Well after thoroughly reading through a large portion of the original issue and this post here, I have a few things I'd like to mention to anyone who wants to take the time to read my short essay here. I hope it sheds some light for people reading. I also want to point out that I hold no ill will to the two users I am going to reply to. I just disagree with some of your points. (I should also mention that I have not personally been affected by this issue. I just see a lot of discussion about the moral responsibilities we have as programmers that are concerning to me.)

Firstly, @macfreek, I would disagree with your statements, too.

True, non-active authors shouldn't be expected to mark stuff as archived. They are non-active. But the OP is not non-active. He took the time to hand the project off. In regards to marking something archived for those who are actually non-active, I would think that should be something built into the ecosystem. NPM and GitHub should probably do that automatically after no maintenance has occurred for some period of time. But neither of those scenarios happened with the OP.

With due respect, @Forevernowandgone you couldn't be more wrong in blaming @dominictarr in any way or form. If his motivation is fun then that's what his motivation is. If he also shared his work, be grateful -- and that's where it ends. Those who decided to use his code are responsible for said decision.

And with due respect to you, @chx, I believe you couldn't be more wrong here. You are making a claim that this guy is wrong, so you obviously believe in some kind of moral absolutes. But then you completely let the OP off the hook in a way that implies moral relativism saying his motivation was "fun", so that's what his motivation is, implying nothing else he did matters? If his motivation was fun, then why publish it online? You don't need to do that to have fun. Publishing online implies you want to help others by providing your software to them. He chose to do so. And we should definitely be thankful to @dominictarr that he did choose to share it, as it has clearly been used by a large portion of the community.

I'm not saying people aren't responsible for using his code. They certainly are. But to resolve @dominictarr of all responsibility makes no sense. Obviously, he is not legally responsible as most people have been saying. But he does hold some responsibility.

Life is full of responsibilities that we incur on ourselves and sometimes we have them thrust upon us without our consent. Think of it like this. If the OP was walking alone down the sidewalk and saw a toddler about to crawl onto a busy roadway, would it not be his moral responsibility as a human to stop the toddler from crawling onto the road? He did not ask for or want that responsibility, but I think any reasonable person would say he should be held responsible (as well as the irresponsible parent mind you) if he had the ability and opportunity to stop harm from coming to the child, yet chose not to do so. In the same manner, he created and offered this code freely online for anyone to use. He then chose to hand that code off to someone else. Whether or not he did any vetting of the guy or not, he chose that action. Then there is this:

As it happened, I was coming around to this decision. A while after giving event-stream away, I shifted 343 modules to an account that I no longer control - so that I can more easily say "no, I can't help, I cannot publish that module anymore". I had been intending to archive them on npm, but neither npm or github have tools to do things like this in bulk, and I had hundreds of modules to disown. I was gonna write a script to do this, I just hadn't gotten around to it yet... At the time of disowning all these modules, I had already transferrered event-stream, and no malicious activity had been reported, so I just removed my self.

He gave away the event-stream code, but decided to not do so for the 343 other modules, so he obviously realized abandoning them was a better option than giving them all away to a stranger. And he states when he was disowning them, he had already transferred event-stream. At any rate he obviously knows he made a bad decision. And I agree that nowhere in his statements (that I've seen at least) has he expressed remorse or apologized for making the bad decision. I think that's the biggest reason as to why so many people are angry with him. It's not that he made the bad decision, it's that he continues to defend himself without expressing remorse.

That being said, it is very easy to just want to defend yourself when you have so openly and on such a large stage been exposed to basically public lashing and vitriol by so many people. It's a very understandable response. But I hope that he will eventually just add that he made a mistake and that he is sorry for it. Explicitly stating it and showing vulnerability here would go a long way towards diminishing a lot of the hatred he's been shown. If you read this, @dominictarr, that's my only advice. But thanks for all the work you have done for the community.

@mirskiy

This comment has been minimized.

mirskiy commented Nov 29, 2018

I wanted to add my support for a distributed audit/review process along the lines of what @PhilippLgh and @eirslett (https://medium.com/@eiriksletteberg/a-proposition-to-collectively-security-audit-the-most-used-npm-packages-36ed8cbc1f8d) are suggesting. I believe this audit process should be more than just a set of signatures; it should include a weakest-link philosophy for dependencies, a trust metric to highlight weaknesses without having to recursively inspect each dependency, and a review process to facilitate the community.

Code review has become a standard part of many developer environments, but it has not yet embedded itself in the open-source culture. It is easy to publish a new package to npm or other package managers - and this is important, keeping the barrier to entry low encourages new members to the community. This also creates millions of points of failure - as we saw in this example, a change made by one person spread to hundreds or thousands of packages through dependencies. The traditional answer has always been, "Audit your dependencies," but I think we can safely say this is unrealistic; sub dependencies are a vulnerability too, so either you have to place trust in your dependencies to audit their dependencies (creating another single point of failure) or you have potentially thousands of dependencies to audit.

Some of the proposed solutions discuss paying maintainers, but this cannot solve the problem. Imagine a scenario where a Bad Actor bribes or compromises a developer of a single-maintainer package. Instead, by allowing distributed review and auditing of commits, we immensely decrease the attack surface and increase the likelihood that an attack like this will be caught sooner. Other solutions mention marking modules as maintained/un-maintained. While this would be a nice feature, it does nothing to mitigate the risk of a single rogue/compromised maintainer.

I imagine the solution consisting of a set of signatures on (ideally) every commit or (at least) every release. This is no different than the code review processes at a large organization - you would never allow code into production if it has only seen one set of eyes. The challenge is determining who to trust - a bad actor could still potentially use bot accounts to create lots of signatures on a malicious commit. This is probably the hardest part of the model, but one that I believe can be solved. One possibility is a web of trust that starts with well known developers in the community and allows vetting or delegation of trust, somewhat similar to Linux's "trusted lieutenants" with many layers. The model should follow a weakest-link philosophy - a package can only be as strong as the weakest of its dependencies.

Unlike others have proposed, I do believe that there needs to be a trust metric in this model. While a metric opens the potential for gaming the system, I do not believe that the model can succeed without it. Unless a centralized set of "auditors" form that can guarantee a package's safety, each developer will still have to inspect the reviewers for each of their dependencies and place trust in them to audit their dependencies - bringing us back to the original trade-off of trust vs. thousands of sub-dependencies to verify.

Such a model would also facilitate some of the other solutions mentioned. As @eirslett discusses, it would allow the formation of bounties and paid auditors to encourage the code reviews. Also, unlike solutions which may increase the barrier to entry to publishing a package, I believe this would encourage it and facilitate the community. As a developer, knowing that a package I publish could potentially be used in someone else's production system greatly increases the burden on me before publishing. While the MIT license lifts the legal responsibility, I still feel a personal responsibility for my work. This would lower that burden, as a package would be reviewed multiple times before it is likely to be used in production.

Ideally, this model would be separate from the existing package managers - there are plenty of times when I see a useful repo on Github that hasn't been published to a package manager. We already use community information to determine the status of the package at a glance - stars, commit frequency, and the author's affiliation/activity - but these metrics still leave a single point of failure.

Not only would this facilitate security, it would encourage the community to grow. I can envision new developers following and auditing popular projects they are using as well as benefiting from the review comments - as many already do from the code reviews at organizations. Obviously, the model of code review is not new, the goal is to extend it past organizations and into the open source community at large.

TLDR; We need a distributed code review model for open source that utilizes trust to remove the thousands of single-point failures that we currently have.

@Stargateur

This comment has been minimized.

Stargateur commented Nov 29, 2018

@eckerdj7

Life is full of responsibilities that we incur on ourselves and sometimes we have them thrust upon us without our consent. Think of it like this. If the OP was walking alone down the sidewalk and saw a toddler about to crawl onto a busy roadway, would it not be his moral responsibility as a human to stop the toddler from crawling onto the road? He did not ask for or want that responsibility, but I think any reasonable person would say he should be held responsible (as well as the irresponsible parent mind you) if he had the ability and opportunity to stop harm from coming to the child, yet chose not to do so. In the same manner, he created and offered this code freely online for anyone to use. He then chose to hand that code off to someone else. Whether or not he did any vetting of the guy or not, he chose that action.

Wrong, please, again, stop talk about what you know nothing, you have legal responsibility to help people if they are in immediate danger, you also have legal responsibility to take care of your child. A code is not a child stop this stupid comparaison, MIT licence explicitly say I don't take any responsibility what so ever. Stop impose your own vision of responsibility, law are fucking here for that.

He gave away the event-stream code, but decided to not do so for the 343 other modules, so he obviously realized abandoning them was a better option than giving them all away to a stranger.

Not at all, again, you understand nothing, he was asked by someone about this project, give it away and then decide to just throw away the other module, obviously he wanted to turn a page and not have to handle futur mail about people asking to maintain his past project. He just do it for this one because it was probably the first where someone trouble him with mail.

It's not that he made the bad decision, it's that he continues to defend himself without expressing remorse.

Again stop impose your moral to other people ! You are totally wrong. He didn't do anything wrong. Also, he didn't defend himself, he just say fact. We are not in a trial.

@yonjah

This comment has been minimized.

yonjah commented Nov 30, 2018

Random people on the internet are getting angry because they trusted some random person on the internet who ended up trusting the wrong random person on the internet.

This sounds like a bad joke but this is how our industry operates.

The anger towards the original maintainer is not justifiable but we can certainly understand where its coming from.
Even a small project will use a few dozen dependencies even if you took the time to check each of those superficially on every update each of those dependencies has it's own dependencies and routinely check all the 3rd party code incorporated into our apps is not an option even for a big and well founded team (and don't forget the OS and other code your server is running to support your app).
So anyone affected is probably feeling defenseless and bruised from this situation and looking for someone to blame is just natural.

So instead of pointing fingers we should thing how as an industry we are going to solve this issue. collective security audits as suggested might be useful but are probably not enough. Validation of code is important but requires a lot of time and a rogue maintainer can easily out resource even the most highly founded audits. So the first step should be validating identity of lead maintainers and maybe even offering some training about basic security concepts specifically related to supply chain attacks so at least we know we can trust the lead maintainer and that he will be cautious about who he give publish permissions and the code he accepts from other contributors.

I don't think this is something the community can handle without the support of NPM and probably Node.js Foundation.
NPM at minimum should offer a way to identify verified packages (who's owners been verified) but should probably handle and fund the personal verification process.

@JoshuaVSherman

This comment has been minimized.

JoshuaVSherman commented Nov 30, 2018

Well said, @dominictarr. This is not a problem with Node. This is not a problem with npm, this is not a problem with you. This is a problem with people being put in a state of responsibility for something they didn't ask to be put in a state of responsibility for.

You wrote code because you wanted to and gave it away free. Someone else decided to depend on that code, which in return got depended on by someone else, next thing you know you're little package is being used by 2/3rds of the internet.. And you're somehow required to give 100% SLA to people who use that code, because they decided to build a business that depends on that code and feel they aren't responsible for paying for it, because IT'S OPEN SOURCE!!!

I see your point, however, there is a problem when people are trying to help maintain some code and submit a pull request to the project, only to have it sit there and never get reviewed or merged, then what?

@KyleMit

This comment has been minimized.

KyleMit commented Nov 30, 2018

Lots of people here blaming @dominictarr as the proximate cause, but missing the larger picture. If a single bad actor can compromise the security of your entire system, it's not a well designed system. Databases with thousands of credit cards don't stay secure because all the employee simultaneously opt to be virtuous. It might be a heavy lift to rule out this class of attack, but it'll remain a viable attack vector if your solution is to just yell at npm authors

@acsteitz

This comment has been minimized.

acsteitz commented Dec 1, 2018

There are many people on here complaining about Dominic's "lack of remorse." Guessing that those people live somewhere that does not allow law suits on a whim. With the magnitude of this incident, if Dominic publically expresses remorse then you can bet someone will construe that as accepting legal responsibility and try to sue him. If you want more people to apologize when they mess up, do something about the courts that allow stupid law suits to proceed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment