RFC: add registry per package per organisation

[baloran]

tl;dr

We want to install some private package from github registry and some public package from npm registry with the same scope organisation.

Why

We use multiple registry, npm for public package, github for private package. We use multiple mono repos and want to host on github registry for simplicity. But we want to share with the community our public package on npm because everyone have his habits on npm registry.

[ruyadorno]

one concern raised by @wesleytodd in the original RRFC:

One new hazard this introduces: in older versions of npm which do not support this feature might result in users installing code from an unexpected registry and therefore opening the door to a RCE or otherwise getting the wrong code. By back porting the feature or atleast an error to npm@6 will help reduce the issue.

Also, will this support unscoped package names? I think it should.

[wesleytodd]

An example of the hazard:

1. A team manages many projects published to an internal registry both scoped @company/* and un-scoped company-*
2. Today they use npm@6 and some hacks on the registry layer to ensure company-* packages never come from the public registry (maybe like @ljharb described with a regexp match)
3. npm@7.1.0 is released with this feature and one developer reads the release notes (someone always does)
4. The entire team gets really excited about removing the registry hacks and updates all the projects
5. The registry hacks are removed 🎉
6. Oops, one Jenkins deployment isn't updated to npm@7.1.0 💥
   6a. One engineer forgot to update npm
   6b. Someone is testing an older node version using nvm and gets npm@6 by default
   6c. Many many other scenarios where the new config is not respected...

This would result in all the company-* packages being loaded from the public registry. An attacker can (and I know for a fact this approach has worked) publish knowingly under that name and just wait for the install to phone home.

There are many more scenarios depending on configurations (I will not post publicly about ones which I have the most direct knowledge of) where this can happen, some which require even less bad luck to hit.

[isaacs]

It seems like this entire hazard goes away if we don't support unscoped package names with this feature (or warn if we see those to point out that they're hazardous for npm v6 users).

[ljharb]

It would still be a hazard if the scope chosen internally matched a public scope, although that’s unlikely.

[isaacs]

It would still be a hazard if the scope chosen internally matched a public scope, although that’s unlikely.

Well, the use case in the OP here is actually a scope that is both internal (on the github packages registry) and external (on the npm public registry).

But I think maybe what you're suggesting is that it'd be a hazard if the scope chosen internally matched a public scope that you do not control.

Discussion notes

I think the plan here is to move forward with this RFC, but with the provision that it only can apply to scoped packages, in order to mitigate the hazards brought up by @wesleytodd and @ljharb.

Additionally (and what might address this in a better way, albeit it with a lot more implementation cost) we should write an RFC for a registry: dependency specifier #275

[mahnunchik]

I've faced with the same issue https://gist.github.com/azu/31530916cbce0fd2fc1f4d8f6cf0fae1 😢

[isaacs]

There wasn't a way to get over the security implications that this would raise.

Addressed a different way in #314.