
Tell HN: Node.js koa-router package transferred to unknown user - niftylettuce
https://github.com/nodejs/package-maintenance/issues/77#issuecomment-463356844
======
binarymax
The npm package ownership process is flawed. Anecdotally, I received an email
from npm support saying someone requested publish rights to a package that I
manage. The default was that the access would be granted if I did not respond
within 30 days.

It's very possible this went through npm support, they received no reply
within the window, and the transfer was granted.

There are good practices around domain names to lock transfer, perhaps npm
should consider adopting similar mechanisms.

\--edit-- for the curious, here is the redacted email chain. I don't want to
call anyone out on this. These things are hard and handling edge cases are
very difficult. I love npm, and host several packages there. I really
appreciate everything they've done for node and javascript, and I think folks
are harder on them than they should be due to some tricky decisions they've
made. But I want things to improve for everyone, so consider this a disclosure
for analysis on how things can get better.
[https://pastebin.com/636v8YSP](https://pastebin.com/636v8YSP)

~~~
pscanf
I've been on the other side of a similar conversation, that eventually got me
the name I wanted after around 30 days. This was around five years ago, when
there were still no scoped packages and the ecosystem was surging in
popularity. I guess in the previous years people had been creating test
packages and forgetting about them, and no doubt some were just squatting
popular names. In my case the package with the name I wanted was empty and
inactive, and there was a human check before it being handed over.

~~~
binarymax
Yes I had guessed the policy is to prevent squatting. But it shouldn't apply
to packages that actually have code sitting in them - anyone could have seen
my package had a bunch of work gone into it, even if it hadn't been updated in
a while. If it's a legit package, no matter how old it is, then the ownership
should stick to the original author by default in perpetuity.

------
amingoia
Please stop harassing me. Let's set the record straight.

The Koa organization did not write, maintain, or ever help with this package.
I wrote it. I maintained it, with help from people who reached out to me
directly (and actually contributed code).

@ZijianHe offered to maintain it, and I agreed to let him maintain it. Our
relationship is not anyone's business. I don't have a relationship to the koa
organization. I don't know them. Furthermore, @niftylettuce has repeatedly in
emails to npm asserted that ZijianHe is Chinese, despite this having nothing
to do with anything, or even knowing whether ZijianHe lives in China. Chinese
developers have contributed more to this repository than anyone from the Koa
organization. This kind of racial scaremongering or guilt by association is
not acceptable. Its offensive. Let's be very clear: Developers from any
ethnicity and nationality are welcome to contribute to open source.

I'm not going to say anything more on this issue. This is beyond ridiculous.

~~~
gnahckire
> Let's set the record straight... @ZijianHe offered to maintain it, and I
> agreed to let him maintain it. Our relationship is not anyone's business.

Why not be transparent about selling the package? Or attempting to do so?

> Chinese developers have contributed more to this repository than anyone from
> the Koa organization. This kind of racial scaremongering or guilt by
> association is not acceptable. Its offensive.

Nice rhetoric here. But you know the Country of origin of most cyber attacks
is China right?

Source: [https://www.csis.org/programs/cybersecurity-and-
governance/t...](https://www.csis.org/programs/cybersecurity-and-
governance/technology-policy-program/other-projects-cybersecurity)

> I'm not going to say anything more on this issue. This is beyond ridiculous.

Suit yourself. But it really isn't. Sorry for all the harassment you're
getting but, it's not exactly unwarranted...

~~~
chrischen
If you pulled up crime statics on black people vs white people, you'd have
similar damning statistics. Rather than prejudicing this "unknown Chinese" guy
why not treat him as a person first and find out who he is, and what he has to
say?

~~~
gnahckire
Fair point. Although one shouldn't discount statistics altogether. Security
experts lean on skepticism to help minimize exposure and discover new things.

Race and nationality aside, the transfer of ownership to an entity that has
zero open source contributions in the js space does look very suspicious. I'm
just surprised that an open source author didn't provide that disclosure to
users of his work.

~~~
chrischen
In almost all cases, including this one, you will have better signals than to
bucket a whole race or culture under a generalized stereotype.

For example i can see at least another Chinese contributor who is against this
who works at Alibaba that commented.

The principle issue here is that the repo was put up for sale, and anyone
paying for the opportunity to maintain a free library should be scrutinized.
This would be true regardless of if they were Chinese, black, or a white guy
from San Francisco.

------
lioeters
Although nothing malicious has happened yet, that change in the readme ("this
package name is for sale") is spammy and concerning. Kudos on niftylettuce
(love your blog!) for raising awareness.

This is yet another example of a (by now fairly known) vulnerability in the
npm package ownership transfer process. Just a few months ago, there was a big
drama with malicious code found in a popular package `event-stream`, placed by
a new unknown owner.

I like one of the ideas in the GitHub issue, that a change in package
ownership should be considered a major semver bump. At least that might reduce
the reach of a bad actor who would buy a popular package for exploitation.

~~~
_bxg1
Woof. I didn't even notice the "for sale" part at first. That's probably the
biggest red flag. You should _never_ sell a backdoor into thousands of
codebases to the highest bidder.

Of course, the real problem is thousands of codebases shouldn't be banking on
the honor system for stuff like this.

------
ZijianHe
Hi all. I am the one who took over the repo. Thanks for some of you guys
reaching out.

I haven't been contributing to open source projects before so I don't have too
much public information on my Github account.

Thus I think it would be a good opportunity for me to join the open source
community by maintaining the koa-router project.

I will start reviewing PRs and getting rid of issues after I finish going thru
the code.

Any suggestions are welcome

------
jeremejevs
Tangential, but koa-router isn't even that great, been using koa-tree-router
[0] instead. Fewer dependencies, no API oddities and long-standing bugs [1],
faster. It's much younger (less battle-testing), and has no regex and multi-
parameter routes, but is worth considering.

[0] [https://github.com/steambap/koa-tree-
router](https://github.com/steambap/koa-tree-router)

[1] [https://github.com/ZijianHe/koa-
router/issues?q=is%3Aissue+i...](https://github.com/ZijianHe/koa-
router/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc)

------
javitury
koa-router was owned by @alexmingoia and not by @koajs. Still it is a central
piece of the koa framework that compromises practically every koa setup. The
only alternative I have found is this:

[https://github.com/koajs/trie-router](https://github.com/koajs/trie-router)

The transition from express to koa has been slow, and this doesn't help. It
will undermine the confidence on the koa framework.

~~~
bearmcbearsly
Now that you can trivially use async functions as express handlers, what are
the major benefits of transitioning to Koa?

~~~
Sytten
None to be honest. I migrated my projects back to express. Most of the
packages for koa are either unmaintained or not very active.

------
ldiracdelta
Maybe transfer of ownership should be a mandatory major version bump with no
option to release to lower major versions anymore.

~~~
pscanf
Transfer of ownership can be done "unofficially" in many ways though, for
instance adding a contributor to the organization which controls the package.
Requiring a major bump could be problematic in many cases (I'm thinking,
@microsoft adding a member to their team would require a major for all their
packages). And one can always sell their entire npm account, and no-one would
notice.

------
AtroxDev
The new owner just confirmed that he purchased the package:
[https://github.com/ZijianHe/koa-
router/issues/494#issuecomme...](https://github.com/ZijianHe/koa-
router/issues/494#issuecomment-463474660)

(in case the comment gets deleted:
[https://i.imgur.com/J5lOiMZ.png](https://i.imgur.com/J5lOiMZ.png))

------
midway
Not commenting about the transfer but the urge from some to move this to the
koajs organization (which is silly request):

Great about koa is that it's not a monoculture like express. express has all
batteries included and lacks a healthy ecosystem. Yes, there is a lot stuff
out but everything in and around express feels broken. Yes, you can use it and
it's ok but you not really happy.

This paired with the same maintainers who also are on connect, express-
generator, etc. They do all together a great job maintaining express but you
feel the lacking pace in all these project. express still lacks hhtp2 (not
turn-key-ready), express-generator is full of strange edge-cases nobody needs
(in the www file) polluting your code. express docs got better but still.

But we as a community need healthy competition and if koa-router moved to
koajs you'd start the next monoculture and new contenders wouldn't have any
chance to establish because there is a default router.

The key to be successful is to build a minimal/barebone product and let others
create additions and not swallowing everything into a slow org.

And tbh, I like koa-router but simple stuff like a regex path matching is not
included where I need my own middleware (I mean it's a few lines but still).

Everyone who don't like this move, fine, fork koa-router and make it better
and we will see if koa-router's new maintainer is a real maintainer who will
push the product. Or just write your own router, it's not that hard.

Forking and improving is open source not complaining in dozen threads and
pressuring people to hand out a repo (this reminds me of office politics and
blackmailing" 'give us the repo or we destroy your and the new maintainer's
reputation online'). I think it's more about getting the SEO-relevant Github
and npm name 'koa-router'.

So guys, just stop it, welcome the new guy and/or fork, I am happy to yarn add
your fork.

------
niftylettuce
To anyone reading this, I'm building a tool to automate this nonsense, at
least until Node/NPM do something about it. Email me at niftylettuce@gmail.com
if you want to get notified once it's up. It will be free and open-source.

~~~
fireattack
>automate this nonsense

What exactly are you automating? A notification system for transferring of
ownership?

~~~
niftylettuce
Everything related to this nonsense

------
gammateam
thats actually a kind of cool attack vector.

------
k__
Is NPM at it again?

~~~
untog
I don't think NPM themselves have done much here. The original owner of the
module sold(!) the package name and transferred it to a new owner. It's not
like this was somehow sneakily stolen.

~~~
jhare
I agree on them not doing much. As in not much at all to help. How about I
just go ask for every package on NPM and see who's busy enough to deal with
that or not?

I love Javascript but the ecosystem stinks.

~~~
yazboo
Could you not do that on PyPi and rubygems as well?

~~~
doublerebel
Absolutely not. PyPi and Rubygems have much more strict and sane ownership
policies to prevent unauthorized takeovers of packages. (Same with apt and
every other major package repo.)

No package in any package manager, if it contains code, and greater than 0
downloads and dependencies, should ever be replaced. The cost of storing an
old package is miniscule compared to a system where anyone can petition for a
package name takeover and cause unlimited cost through the effects of
takeover. 30 days is absurdly short in the lifetime of software and does
nothing good for the community. Package squatting is not a real problem for
anyone.

In this case, the owner wanted the ownership change so it's really a non-
event.

~~~
krainboltgreene
> Rubygems have much more strict and sane ownership policies to prevent
> unauthorized takeovers of packages

No we don't. Our process is just as secure as npm's. Please stop talking about
things you don't actually know.

