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