[NikxDa]

> Contrary to what npm states, this package actually depends on one of our aforementioned spam packages. This is a by-product of how npm handles and displays dependencies to users on its website.

For me personally, this is the biggest surprise and takeaway here. By simply having a key inside package.json's dependencies reference an existing NPM package, the NPM website links it up and counts it as a dependency, regardless of the actual value that the package references (which can be a URL to an entirely different package!). I think this puts an additional strain on an already fragile dependency ecosystem, and is quite avoidable with some checks and a little bit of UI work on NPM's side.

[louislang]

(Full disclosure: I'm one of the co-founders @ Phylum)

We could do a full write-up on npm's quirks and how one could take advantage of them to hide intent.

Consider the following from the post's package.json:

    "axios": "https://registry.npmjs.org/@putrifransiska/kwonthol36/-/kwonthol36-1.1.4.tgz"

Here it's clear that the package links to something in a weird, non-standard way. A manual review would tell you that this is not axios.

The package.json lets you link to things that aren't even on npm [1]. You could update this to something like:

    "axios": "git://cdnnpmjs.com/axios"

And it becomes less clear that this is not the thing you were intending. But at least in this case, it's clear that you're hitting a git repository somewhere. What about if we update it to the following?

    "axios": "axiosjs/latest"

This would pull the package from GitHub, from the org named "axiosjs" and the project named "latest". This is much less clear and is part of the package.json spec [2]. Couple this with the fact that the npm website tells you the project depends on Axios, and I doubt many people would ever notice.

[1] https://docs.npmjs.com/cli/v10/configuring-npm/package-json#...

[2] https://docs.npmjs.com/cli/v10/configuring-npm/package-json#...

[aragilar]

This feels like the more important takeaway (and feels like an actual security bug), I'm surprised this so buried in the article...

[OptionOfT]

And worse, it shows axios, and links to the actual axios package.

https://www.npmjs.com/package/sournoise?activeTab=dependenci...

If it would show axios and link to the package provided in package.json, that at least would be better.

But here they actually link to the wrong package.

[3np]

You should think of the package metadata as originating from the publisher, not from the registry. Aside from the name, version, and (generated) dist and maintainers fields, I don't think any of it is even supposed to be validated by the registry?

Agreed the website UX is confusing and could be better but in general package metadata is just whatever the publisher put there and it's up to you to verify if you care about veracity.

[pas]

the fucking website processes it and after some mighty compute somehow shits out the wrong link. it's actively making things worse by trying to be helpful.

confusing is one thing, but there's a screaming security chasm around that innocent little UX problem.

MS bought npmjs and now it's LARPing as some serious ecosystem (by showing how many unresolved security notices installed packages have) while they cannot be arsed to correctly show what's actually in the metadata?

[brynb]

this is a little too stoic a take with respect to a tool that very unserious people building things for serious but non-technical people use on a daily basis. i think we should strive for more. npm can continue to exist in its very libertarian form, but perhaps there's room for something that cares a bit more about caution