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