7 ms·

I’ll be the first to say it: it looks like breaking everything down into a dependency graph of a million tiny packages that nobody understands and letting anyon

by padjo 3y ago

I’ll be the first to say it: it looks like breaking everything down into a dependency graph of a million tiny packages that nobody understands and letting anyone publish anything they like might have been a bad idea.

dcsommer 3y ago
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.
agloe_dreams 3y ago
I work arch in a modern TS Angular Client for a larger education org and I'm shocked by the number of amateur devs and external contractors who think the solution for everything is 'just add a package'. Need to filter arrays in a pipe in one spot? Package. Paginate an array into a set of defined length arrays so you can do faux pagination in the ui? Package. Need a button of the design in our design system? Material UI and a hell of a lot of CSS, here we come! I basically act as a middleman whose job is 'THIS IS A ONE LINE PIPE!'
- thefounder 3y ago
  Perhaps that's also due the lack of a proper standard library like every other language on this planet has.
  - ljm 3y ago
    And back in the day it was necessary because there weren't polyfills and there weren't build tools. Nowadays your JS is being run through Typescript or some other JS bundler and it's converting your code into something every browser can support. If you're still using Lodash or Ramda or whatever it's because the standard library isn't quite as expressive as they are sometimes.
  - paulddraper 3y ago
    No mainstream language has a built-in GUI utilities. (Except Java....maybe.)
    - throwawaymobule 3y ago
      I think tkinter is included with Python, but other frameworks are more popular. I struggle to think of any others.
- jasmer 3y ago
  [dead]
- thephyber 3y ago
ashishbijlani 3y ago
We’ve built an open-source tool, called Packj [1], to offer developers more insights into packages, such as risky install hooks, embedded binary blobs, and other malicious/risky packages. It performs static/dynamic/metadata analysis to look for "suspicious” attributes. 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
rcme 3y ago
What’s the alternative? Ultimately, the issue isn’t “a dependency graph of a million tiny packages” but rather running other people’s code. If you read the attack details, this is a targeted campaign where people are being tricked into running untrusted code. I don’t see how removing small dependencies solves that problem.
- jaredsohn 3y ago
  I think a benefit of a smaller number of larger packages is reduces the number of parties you need to trust. The people in charge of each larger package can review contributions made to it and have the authority to reject code that includes attacks. If a larger package doesn't do a good job of preventing attacks, its reputation will decline and because there are fewer packages involved it is easy to remember these reputations.
  - ljm 3y ago
    It's never as simple as finding exploits in code review though. Trusted accounts are compromised or the credentials to the package manager are compromised or there is some other supply chain attack. Larger packages tend to have a lot more community and governance around them than your typical JS-style function-as-a-dependency left-pad affair, so maybe they're safer if computer accounts are gatekeeping the published artifacts rather than having individuals embed their personal keys or tokens into the publishing pipeline. I've had this debate before and, as far as dependencies go, sometimes you have to rip the bandaid off and audit your shit, and understand why exactly you outsourced something to a package.
  - thephyber 3y ago
    That seems intuitive. I agree in the sense that smaller supply chain surface area is easier to secure/verify. But it also makes the developers/maintainers of the few packages much brighter targets. I’m more of a fan of standardizing how libraries can be rated, evaluated, trusted, marketed, etc. we need more efforts analogous to Consumer Reports / Underwriters Laboratories. So far there are a few for-profit companies in this space, including Google.
- 3y ago
userbinator 3y ago
Remember the Left-Pad debacle? That was already 7(!) years ago, yet I still remember like it was yesterday: https://news.ycombinator.com/item?id=11348798 https://news.ycombinator.com/item?id=11348798 It's not surprising that this is continuing to happen in JavaScript, the language whose userbase could actually be considered largely computer-illiterate. That's not to say other languages don't have the same problems, but in my experience those who have experience with lower-level languages are more likely to have come from being power users and thus have a reasonable amount of computer literacy. In contrast, the JS world is full of people who, lured by the promise of a well-paying easy job, "teach" themselves via the most shortcut-filled way and churn out a torrent of barely-working code that relies on others' barely-working code. It's pure quantity over quality and no one really understands what they're doing.
- space_fountain 3y ago
  I kinda hate this take and to be clear this is coming from someone who did learn at the low level first: objective c then c++ with some fiddling with assembly and fpgas along the way. In my experience JS programmers are people who want to get things done and see results they can touch. It does have many inexperienced programmers, but because it's one of the better languages to learn if you want to get into programing. The people I saw learning it when I co-led an on campus club focused on encourage people to build things and a hacker mentality were interested in it because it was the path to building things they wanted to build not because it was the path to riches
- itisit 3y ago
  The market asked for these developers, and it got them. Their inexperience is not a symptom of a decided ineptitude or nonchalance towards CS fundamentals. It’s a case of getting what’s required for a job (web apps and crud backends) and not much more.
  - namaria 3y ago
    I'd argue that if you limit your learning to what you need to get a job and not much more, you are exemplifying decided ineptitude and a nonchalant attitude towards the science that underpins your trade.
Freedom2 3y ago
Thank you for being the first to say this! I can't believe no one has said this before.

by padjo 3y ago

dcsommer 3y ago

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.

agloe_dreams 3y ago

I work arch in a modern TS Angular Client for a larger education org and I'm shocked by the number of amateur devs and external contractors who think the solution for everything is 'just add a package'. Need to filter arrays in a pipe in one spot? Package. Paginate an array into a set of defined length arrays so you can do faux pagination in the ui? Package. Need a button of the design in our design system? Material UI and a hell of a lot of CSS, here we come! I basically act as a middleman whose job is 'THIS IS A ONE LINE PIPE!'

thefounder 3y ago
Perhaps that's also due the lack of a proper standard library like every other language on this planet has.
- ljm 3y ago
  And back in the day it was necessary because there weren't polyfills and there weren't build tools. Nowadays your JS is being run through Typescript or some other JS bundler and it's converting your code into something every browser can support. If you're still using Lodash or Ramda or whatever it's because the standard library isn't quite as expressive as they are sometimes.
- paulddraper 3y ago
  No mainstream language has a built-in GUI utilities. (Except Java....maybe.)
  - throwawaymobule 3y ago
    I think tkinter is included with Python, but other frameworks are more popular. I struggle to think of any others.
jasmer 3y ago
[dead]
thephyber 3y ago

ashishbijlani 3y ago

We’ve built an open-source tool, called Packj [1], to offer developers more insights into packages, such as risky install hooks, embedded binary blobs, and other malicious/risky packages. It performs static/dynamic/metadata analysis to look for "suspicious” attributes. 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj

rcme 3y ago

What’s the alternative? Ultimately, the issue isn’t “a dependency graph of a million tiny packages” but rather running other people’s code. If you read the attack details, this is a targeted campaign where people are being tricked into running untrusted code. I don’t see how removing small dependencies solves that problem.

jaredsohn 3y ago
I think a benefit of a smaller number of larger packages is reduces the number of parties you need to trust. The people in charge of each larger package can review contributions made to it and have the authority to reject code that includes attacks. If a larger package doesn't do a good job of preventing attacks, its reputation will decline and because there are fewer packages involved it is easy to remember these reputations.
- ljm 3y ago
  It's never as simple as finding exploits in code review though. Trusted accounts are compromised or the credentials to the package manager are compromised or there is some other supply chain attack. Larger packages tend to have a lot more community and governance around them than your typical JS-style function-as-a-dependency left-pad affair, so maybe they're safer if computer accounts are gatekeeping the published artifacts rather than having individuals embed their personal keys or tokens into the publishing pipeline. I've had this debate before and, as far as dependencies go, sometimes you have to rip the bandaid off and audit your shit, and understand why exactly you outsourced something to a package.
- thephyber 3y ago
  That seems intuitive. I agree in the sense that smaller supply chain surface area is easier to secure/verify. But it also makes the developers/maintainers of the few packages much brighter targets. I’m more of a fan of standardizing how libraries can be rated, evaluated, trusted, marketed, etc. we need more efforts analogous to Consumer Reports / Underwriters Laboratories. So far there are a few for-profit companies in this space, including Google.
3y ago

userbinator 3y ago

Remember the Left-Pad debacle? That was already 7(!) years ago, yet I still remember like it was yesterday: https://news.ycombinator.com/item?id=11348798 https://news.ycombinator.com/item?id=11348798 It's not surprising that this is continuing to happen in JavaScript, the language whose userbase could actually be considered largely computer-illiterate. That's not to say other languages don't have the same problems, but in my experience those who have experience with lower-level languages are more likely to have come from being power users and thus have a reasonable amount of computer literacy. In contrast, the JS world is full of people who, lured by the promise of a well-paying easy job, "teach" themselves via the most shortcut-filled way and churn out a torrent of barely-working code that relies on others' barely-working code. It's pure quantity over quality and no one really understands what they're doing.

space_fountain 3y ago
I kinda hate this take and to be clear this is coming from someone who did learn at the low level first: objective c then c++ with some fiddling with assembly and fpgas along the way. In my experience JS programmers are people who want to get things done and see results they can touch. It does have many inexperienced programmers, but because it's one of the better languages to learn if you want to get into programing. The people I saw learning it when I co-led an on campus club focused on encourage people to build things and a hacker mentality were interested in it because it was the path to building things they wanted to build not because it was the path to riches
itisit 3y ago
The market asked for these developers, and it got them. Their inexperience is not a symptom of a decided ineptitude or nonchalance towards CS fundamentals. It’s a case of getting what’s required for a job (web apps and crud backends) and not much more.
- namaria 3y ago
  I'd argue that if you limit your learning to what you need to get a job and not much more, you are exemplifying decided ineptitude and a nonchalant attitude towards the science that underpins your trade.

Freedom2 3y ago

Thank you for being the first to say this! I can't believe no one has said this before.