Request: Warn on non-scoped dependency packages

[mcandre]

Is there an existing issue for this?

• [X] I have searched the existing issues

This issue exists in the latest npm version

• [X] I am using the latest npm

Current Behavior

NPM silently ignores scoped packages.

Note that eslint is unable to help, due to eslint's insistence on not implementing rules outside of the narrow viewpoint of ECMAScript syntax. So another linter avenue is needed, like stock NPM (+ Yarn).

Expected Behavior

NPM presents a warning about spoofing attacks for non-scoped dependencies, including runtime dependencies, dev dependencies, and transitive dependencies.

Steps To Reproduce

npm install

Environment

No response

[ljharb]

You can write your own linter plugin if that's what you want.

Most packages are unscoped, and the risks are actually higher for scoped packages than unscoped ones, because of frequent use of internal scopes without reserving the corresponding public scope.

[mcandre]

Most packages are unscoped, and the risks are actually higher for scoped packages than unscoped ones, because of frequent use of internal scopes without reserving the corresponding public scope.

Note that most violations of scoped packages locally are good faith contributors just doing ordinary work to improve projects owned by other orgs.

I think that problem is primarily one of documentation and good habits.

Long term, NPM may one day implement an org (contributor) membership option into the npm CLI's authorization system. By default, npm install would refuse to build locally sourced packages for scopes that the user is not a member of. With an environment variable or npm config option to conveniently disable the rule. Initially this enforcement would be disabled by default, given a period of time for the industry to evaluate, and eventually (breaking change) enabled by default.

I still think scoped packages are overall safer, and would like a warning to automate scanning for non-scoped packages. That's so much easier to implement than a fancy local org membership policing system. We can begin by having the rule disabled by default.

If scope is truly less secure, then we should deprecate it.

[ljharb]

It would be hugely disruptive and largely unactionable to have this kind of warning, and I think it'd be very inappropriate for npm to do it.

If you want to lint for it, you can make your own eslint plugin.

[mcandre]

Request that we deprecate unscoped packages.

That's a low impact change with manageable risk of breaking behavior. We can establish an expiration date, a year or two in advance, for packages to migrate to scoped editions.

Before then, we should warn when uploading or downloading unscoped packages, in order to give the industry time to react.

The industry may indeed take a long time to significantly transition over. The warning can include an opt-in CLI option, environment variable, or npm config setting to provide security conscious users the ability to choose to treat the warning as an exit-nonzero error.

[ljharb]

It's a massive impact change, since most packages are unscoped, and warning people who install them doesn't mean it's actionable to fix them.

Both scoped and unscoped packages should remain first-class forever.

[mcandre]

Indeed, this is a breaking change. It won't happen overnight. But the community can gradually migrate to proper scoped packages in time.

Published a basic linter to assist with identifying non scoped packages.

https://github.com/mcandre/periscope

[ljharb]

It's not a desirable change, and the entirety of the community will never complete such a migration.