3 ms·

Many people here are saying that the problem had been in the code base for years, was super obvious, and that just no one looked at the code. I think that it i

Many people here are saying that the problem had been in the code base for years, was super obvious, and that just no one looked at the code. I think that it is much more relevant that the node community does do many micro packages, that it makes so much nose to look at the quality of pulled in packages. I recently pulled down a web app (Zulip) the packages.json expands to almost 1400 npm packages. How is any human going to look at all that. And apparently it is "normal" for an npm project to have that many dependencies. Too me this is madness. It is impossible to know the quality of all those packages.

pi-squared 8y ago
I am not a fan of the whole javascript craze but for comparison on my desktop machine with I assume average setup of ElementaryOS: $ apt list --installed | wc -l 2394 And on my server the number is 502. Couldn't the same argument be applied here as well? I understand that (probably) users of Ubuntu are more involved than supporting npm packages (or... are they) but it's still a lot of packages to eyeball.
- JoshTriplett 8y ago
  Not the same thing. Your desktop install might include a few thousand packages total, but that doesn't mean any significant number of packages pull in a thousand dependencies by themselves. Node packages might consist of a single function.
- georgyo 8y ago
  Sure, but the major difference is that those packages are for everything on your system. Dependencies are often added very carefully. In the node case it is not uncommon for a small app to include 50 small packages, and then those packages pulled in 30 unique smaller packages each (on average). Imagine you did an apt upgrade on your system, or decided to install a new package and it said it was going to install 1500 new packages. Would you continue? It would definitely make me pause for a while. But this is the norm in the node world, and people seem to think it is a good idea.
  - deleted 8y ago
    [deleted]
- throwaway5752 8y ago
  I think that's the point. Outside of very few operating systems and languages with the organization and history supporting them, there's not much that one should trust. Since you can't validate every package yourself, you have to ask yourself if you trust your counterparty. Do you trust ElementaryOS to do have dozens of people validating upstreams before pulling into stable and correctly doing proper package source integrity steps like Red Hat, Canonical, SUSE, et al do? I know they are Ubuntu LTS based but what are the additional packages and how carefully are they curated, built, and stored? May the answer is to not use Node or ElementaryOS depending on how important security is to you. May I'm the weirdo for critically inspecting 3rd party libraries before including them and looking at the transitive dependencies they pull along.
- megous 8y ago
  The trust model of linux distro is different from NPM. Dependning on the distro, there may be many maintainers who are separate from upstream developers. These maintainers may manage 5-10 pcakages on average and usually keep tabs on the upstream. There's just no equivalent of maintainers in the NPM land.
- cyphar 8y ago
  That is for everything required to run an entire operating system. You're actually putting Node's micro-package madness into even more of a negative light from this comparison -- if it takes only several hundred packages to run an entire distribution, why is it reasonable to require that many packages to run a single web application (not to mention that most distribution packages don't depend on hundreds of others)? The difference is that the only people looking into NPM packages are the Node community. The entire Linux community -- which includes a large portion of the Node community mind you -- looks into the set of packages you are looking at (yes, we've had a bad rap in recent years -- but in our defence we really are trying). I'm a little biased with regards to distributions (I work for SUSE), but I like to think that working on a distribution has given me a much better understanding of how much work goes into those packages. I don't think you could adequately replicate most of that engineering in the time that most micro-package ecosystems have been around.
bunderbunder 8y ago
I'm starting to wonder if this is just a fundamental weakness of open source software. Compare with a commercial platform, such as .NET or Cocoa - there you've got more "batteries included" libraries, with relatively large, standardized packages that have short dependency trees, being maintained by people who are paid to pay attention to these sorts of details. This isn't to say that commercial software is bug-free - far from it. If something passes code review, it's not going to be looked at again until someone's being paid to look at it again. Which gets you to a similar place as with open source: Software is buggy. Mostly, though, it leaves me thinking that the whole ideal of, "It's open source, so you can assume many eyes are looking at it," is a pipe dream. Probably the bystander effect is closer to the truth: If it's a small project, I'm relatively likely to at least cursorily look over the code before taking a dependency on it. If it's a big project, though, I just assume someone else is doing that. Just like everyone else. If it's a big project taking dependencies on small projects, though, that seems to be the worst situation. Nobody can make sense of that.
- xorcist 8y ago
  Look inside that "commercial" software of yours, chances are that it bundles both five crappy js libs but also a vulnerable version of gzip. Large parts of the code of any non-trivial software package will be open source code. There are literally people who makes their living from pointing these things out. Unless your software is among the absolutely most widespread, chances are it's not audited at all. (Also, can we please leave the perceived distinction between "commercial" and "open source" in the 90s where it belongs?)
jmull 8y ago
I think it’s a misapprehension to focus on the granularity of release items (packages). Why should that especially influence the security (or other variables of quality) of the underlying source? If a given app includes 1400 pieces of code, does it matter that you can discern all 1400 externally vs if all 1400 are bundled into a single package? However it’s bundled, there’s code beneath for it all, all with the same potential problems. All of it with the same need to be reviewed and/or trusted. If anything, the transparency may help. It’s certainly hard for me to see why it hurts.

pi-squared 8y ago

I am not a fan of the whole javascript craze but for comparison on my desktop machine with I assume average setup of ElementaryOS: $ apt list --installed | wc -l 2394 And on my server the number is 502. Couldn't the same argument be applied here as well? I understand that (probably) users of Ubuntu are more involved than supporting npm packages (or... are they) but it's still a lot of packages to eyeball.

JoshTriplett 8y ago
Not the same thing. Your desktop install might include a few thousand packages total, but that doesn't mean any significant number of packages pull in a thousand dependencies by themselves. Node packages might consist of a single function.
georgyo 8y ago
Sure, but the major difference is that those packages are for everything on your system. Dependencies are often added very carefully. In the node case it is not uncommon for a small app to include 50 small packages, and then those packages pulled in 30 unique smaller packages each (on average). Imagine you did an apt upgrade on your system, or decided to install a new package and it said it was going to install 1500 new packages. Would you continue? It would definitely make me pause for a while. But this is the norm in the node world, and people seem to think it is a good idea.
- deleted 8y ago
  [deleted]
throwaway5752 8y ago
I think that's the point. Outside of very few operating systems and languages with the organization and history supporting them, there's not much that one should trust. Since you can't validate every package yourself, you have to ask yourself if you trust your counterparty. Do you trust ElementaryOS to do have dozens of people validating upstreams before pulling into stable and correctly doing proper package source integrity steps like Red Hat, Canonical, SUSE, et al do? I know they are Ubuntu LTS based but what are the additional packages and how carefully are they curated, built, and stored? May the answer is to not use Node or ElementaryOS depending on how important security is to you. May I'm the weirdo for critically inspecting 3rd party libraries before including them and looking at the transitive dependencies they pull along.
megous 8y ago
The trust model of linux distro is different from NPM. Dependning on the distro, there may be many maintainers who are separate from upstream developers. These maintainers may manage 5-10 pcakages on average and usually keep tabs on the upstream. There's just no equivalent of maintainers in the NPM land.
cyphar 8y ago
That is for everything required to run an entire operating system. You're actually putting Node's micro-package madness into even more of a negative light from this comparison -- if it takes only several hundred packages to run an entire distribution, why is it reasonable to require that many packages to run a single web application (not to mention that most distribution packages don't depend on hundreds of others)? The difference is that the only people looking into NPM packages are the Node community. The entire Linux community -- which includes a large portion of the Node community mind you -- looks into the set of packages you are looking at (yes, we've had a bad rap in recent years -- but in our defence we really are trying). I'm a little biased with regards to distributions (I work for SUSE), but I like to think that working on a distribution has given me a much better understanding of how much work goes into those packages. I don't think you could adequately replicate most of that engineering in the time that most micro-package ecosystems have been around.

bunderbunder 8y ago

I'm starting to wonder if this is just a fundamental weakness of open source software. Compare with a commercial platform, such as .NET or Cocoa - there you've got more "batteries included" libraries, with relatively large, standardized packages that have short dependency trees, being maintained by people who are paid to pay attention to these sorts of details. This isn't to say that commercial software is bug-free - far from it. If something passes code review, it's not going to be looked at again until someone's being paid to look at it again. Which gets you to a similar place as with open source: Software is buggy. Mostly, though, it leaves me thinking that the whole ideal of, "It's open source, so you can assume many eyes are looking at it," is a pipe dream. Probably the bystander effect is closer to the truth: If it's a small project, I'm relatively likely to at least cursorily look over the code before taking a dependency on it. If it's a big project, though, I just assume someone else is doing that. Just like everyone else. If it's a big project taking dependencies on small projects, though, that seems to be the worst situation. Nobody can make sense of that.

xorcist 8y ago
Look inside that "commercial" software of yours, chances are that it bundles both five crappy js libs but also a vulnerable version of gzip. Large parts of the code of any non-trivial software package will be open source code. There are literally people who makes their living from pointing these things out. Unless your software is among the absolutely most widespread, chances are it's not audited at all. (Also, can we please leave the perceived distinction between "commercial" and "open source" in the 90s where it belongs?)

jmull 8y ago

I think it’s a misapprehension to focus on the granularity of release items (packages). Why should that especially influence the security (or other variables of quality) of the underlying source? If a given app includes 1400 pieces of code, does it matter that you can discern all 1400 externally vs if all 1400 are bundled into a single package? However it’s bundled, there’s code beneath for it all, all with the same potential problems. All of it with the same need to be reviewed and/or trusted. If anything, the transparency may help. It’s certainly hard for me to see why it hurts.