At least npm has namespaces (scopes) to group packages by trustable entity. I wish cargo had namespaces. It's a big miss for an otherwise security conscientious project imo.
NPM exposes that info in the _npmUser field: https://github.com/npm/registry/blob/master/docs/REGISTRY-AP.... That gives "name" (NPM username) and email.
While there are thousands of packages, I bet there's a much smaller number of publishers to worry about.
Like this guy pretty much has a separate NPM package for every single function that he writes: https://www.npmjs.com/~sindresorhus (1162 packages under his name alone, maybe even more in other namespaces).
Doesn't matter if you trust them; can you trust the 100+ dependencies they pull in? If it's a large package, you can be certain that they aren't verifying their deps.
Always.
It's a poor ecosystem, dominated by untrustworthy participants. There's no digital identity verification of participants or their packages. anyone can claim to be whoever they want to.
Pointing this out is not pearl clutching, and if it was easy to solve it would have been done so by now.
The only way to trust a package is to verify the authors identity and verify that that identity generated that package.
But tying packages to domain names means that all these low effort two line package authors have to put in non-minimal effort (acquire a domain, maintain the cert) which is not going to happen.
It works fine in practice; I've seen at least one big company do it. It doesn't happen in the public ecosystem only because people don't care enough.
> It's a poor ecosystem, dominated by untrustworthy participants. There's no digital identity verification of participants or their packages. anyone can claim to be whoever they want to.
Fixing that isn't hard. The Java/Maven ecosystem already enforces OpenPGP signing of all package uploads; NPM could do the same if they wanted.