3 ms·

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

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.

koolba 3y ago
More important than the namespace is who published the package. I'm more inclined to trust an individual I know who takes security than a namespace that may change hands. NPM exposes that info in the _npmUser field: https://github.com/npm/registry/blob/master/docs/REGISTRY-API.md#getpackageversion 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 https://www.npmjs.com/~sindresorhus (1162 packages under his name alone, maybe even more in other namespaces).
- skydhash 3y ago
  Wow. There is even one package to not use a JavaScript object: https://www.npmjs.com/package/conf https://www.npmjs.com/package/conf
- lelanthran 3y ago
  > More important than the namespace is who published the package. I'm more inclined to trust an individual I know who takes security than a namespace that may change hands. 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.
  - lmm 3y ago
    So write a tool that checks the authors of all your transitive dependencies against your trusted list. (Or, more likely, pull one in, I'm sure someone's written that already). Are you a programmer or not? The amount of pearl-clutching over numbers of dependencies is something I'll never understand.
    - lelanthran 3y ago
      It works nicely in your theory, in practice no one does this because you always have a chain in which some dep is not trusted. 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.
      - lmm 3y ago
        > It works nicely in your theory, in practice no one does this because you always have a chain in which some dep is not trusted. 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.
TheCoelacanth 3y ago
But unfortunately the culture around npm is such that even entities that should be trustworthy pull in random transitive dependencies that aren't well vetted.

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.

koolba 3y ago

More important than the namespace is who published the package. I'm more inclined to trust an individual I know who takes security than a namespace that may change hands. NPM exposes that info in the _npmUser field: https://github.com/npm/registry/blob/master/docs/REGISTRY-API.md#getpackageversion 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 https://www.npmjs.com/~sindresorhus (1162 packages under his name alone, maybe even more in other namespaces).

skydhash 3y ago
Wow. There is even one package to not use a JavaScript object: https://www.npmjs.com/package/conf https://www.npmjs.com/package/conf
lelanthran 3y ago
> More important than the namespace is who published the package. I'm more inclined to trust an individual I know who takes security than a namespace that may change hands. 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.
- lmm 3y ago
  So write a tool that checks the authors of all your transitive dependencies against your trusted list. (Or, more likely, pull one in, I'm sure someone's written that already). Are you a programmer or not? The amount of pearl-clutching over numbers of dependencies is something I'll never understand.
  - lelanthran 3y ago
    It works nicely in your theory, in practice no one does this because you always have a chain in which some dep is not trusted. 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.
    - lmm 3y ago
      > It works nicely in your theory, in practice no one does this because you always have a chain in which some dep is not trusted. 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.

TheCoelacanth 3y ago

But unfortunately the culture around npm is such that even entities that should be trustworthy pull in random transitive dependencies that aren't well vetted.