5 ms·

More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on

by mtkd 9y ago

More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's potentially kryptonite for a production datacenter.

raesene6 9y ago
Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
- mbrock 9y ago
  Maybe most of those 500,000 packages simply shouldn't be trusted. There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal. I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.
  - raesene6 9y ago
    Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility. I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.
    - mbrock 9y ago
      I think it might just not have happened yet. The npm community can be pretty creative and enthusiastic! I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc. Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved". I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...
      - raesene6 9y ago
        So, apologies for being a bit cynical here, but I don't see this one being addressed any time soon. it's been at least 5 years since npm started getting scrutiny relating to security weaknesses https://blog.andyet.com/2012/03/08/compromising-the-integrity-of-the-npm-registry/ https://blog.andyet.com/2012/03/08/compromising-the-integrit... and 4 years since Rubygems was compromised http://blog.rubygems.org/2013/01/31/data-verification.html http://blog.rubygems.org/2013/01/31/data-verification.html and yet, I don't see substantial movements relating to package security and trustability in these repo's. To be clear I'm not suggesting these two are any worse than others, they're just large repo's who have had incidents in the past. The problem here (to my view) is that increasing the security of package repo's will slow down releases (additional checks take time) and cost money (additional security, hosting etc) and until there's a market demand for those service, they won't happen.
        mbrock 9y ago
        I'm skeptical too. But if I think like a sci-fi writer I can vaguely imagine ways for it to actually happen. That open source maintenance happens at all is pretty remarkable, so I think this thing, with an appropriate concept and some good tools (with emojis in their command line output), is at least vaguely plausible...
        Jach 9y ago
        I don't see any reason it can't be done, either, in theory, and that's with the manual approach. Fancier ideas are viable too, but 500k is still relatively tiny and a manually tractable number. Incremental reviews starting today by many coordinating groups in the node community would take a while to complete, maybe a few years, but with some sensible ordering heuristics like e.g. the most downloaded first, or the most suspicious names first, some value could be produced quickly. But it won't happen, package vetting isn't really a value in these communities. (And that might not really be a bad thing, at least for now...)
- gkya 9y ago
  Five hundred thousand packages, am I reading it right? I dont believe top ten OS package managers combined would reach that number. Either this is a typo or it's crazy.
  - mbrock 9y ago
    JS is the most popular language on GitHub by far, and npm is a public site where anyone can instantly upload as many new packages as they want...
  - raesene6 9y ago
    Not a typo, http://www.modulecounts.com/ http://www.modulecounts.com/ has the details. npm is adding 497/day at the moment.
    - gkya 9y ago
      This [1] is npm growth compared to anything else. God this can't be safe nor sane... [1] https://imgur.com/a/enjvR https://imgur.com/a/enjvR
      - eeZah7Ux 9y ago
        The left-pad disaster has been predicted well in advance...
        concede_pluto 9y ago
        There's nothing especially awful about left-pad being its own package, the disaster was because a huge number of developers were betting on npm to somehow be highly available (despite being donated by its admins at no cost and with no committed SLA) rather than vendoring their deps.
        eeZah7Ux 9y ago
        Vendoring thousands of tiny libs is even worse. Trusting many lesser known, tiny libs is more risky than few, big well known ones. Also, they are not vetted and there are much more opportunities for an attacker to sneak in a backdoored lib on the edge of the dependency graph. Finally, due to vendoring there's no way to receive timely drop-in security fixes for all dependencies from a trusted source.
- cdnsteve 9y ago
  If there was a business/enterprise offering with extra security I'm sure they'd have a long list of people who would sign up and happily pay for it.
  - raesene6 9y ago
    Those service already exit, e.g. https://www.sourceclear.com/ https://www.sourceclear.com/ whilst I hope they're doing well, I don't think they've made significant in-roads into the volume of people using open source software library repo's.
    - cdnsteve 9y ago
      It needs to be part of PyPi directly, I would have a difficult time trusting and unknown third-party.
  - simon3 9y ago
    The conda package manager is free and generally feels like a professional package manager like yum or apt-get.
    - edraferi 9y ago
      Yes, Conda [0] is a package manager designed by Continuum Analytics (now Anaconda, Inc.) to support their Anaconda Distribution [1]. The distribution is free, and the Conda client is open source. However, Anaconda sells several enterprise products, including an on-premise Conda server ("Anaconda Repository"). In general, Conda does more package verification than pip, and the packages in the Anaconda distribution are more thoroughly vetted than PyPi. Conda-Forge [2] provides an escape hatch for less-vetted community code. [0] https://conda.io/docs/index.html https://conda.io/docs/index.html [1] https://www.anaconda.com/distribution/ https://www.anaconda.com/distribution/ [2] https://conda-forge.org/ https://conda-forge.org/
- fha 9y ago
  It always worries me when I install a well-known or large package from npm and it ends up downloading dozens of dependencies maintained by disparate and unaccountable github users.

by mtkd 9y ago

raesene6 9y ago

Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.

mbrock 9y ago
Maybe most of those 500,000 packages simply shouldn't be trusted. There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal. I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.
- raesene6 9y ago
  Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility. I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.
  - mbrock 9y ago
    I think it might just not have happened yet. The npm community can be pretty creative and enthusiastic! I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc. Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved". I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...
    - raesene6 9y ago
      So, apologies for being a bit cynical here, but I don't see this one being addressed any time soon. it's been at least 5 years since npm started getting scrutiny relating to security weaknesses https://blog.andyet.com/2012/03/08/compromising-the-integrity-of-the-npm-registry/ https://blog.andyet.com/2012/03/08/compromising-the-integrit... and 4 years since Rubygems was compromised http://blog.rubygems.org/2013/01/31/data-verification.html http://blog.rubygems.org/2013/01/31/data-verification.html and yet, I don't see substantial movements relating to package security and trustability in these repo's. To be clear I'm not suggesting these two are any worse than others, they're just large repo's who have had incidents in the past. The problem here (to my view) is that increasing the security of package repo's will slow down releases (additional checks take time) and cost money (additional security, hosting etc) and until there's a market demand for those service, they won't happen.
      - mbrock 9y ago
        I'm skeptical too. But if I think like a sci-fi writer I can vaguely imagine ways for it to actually happen. That open source maintenance happens at all is pretty remarkable, so I think this thing, with an appropriate concept and some good tools (with emojis in their command line output), is at least vaguely plausible...
        Jach 9y ago
        I don't see any reason it can't be done, either, in theory, and that's with the manual approach. Fancier ideas are viable too, but 500k is still relatively tiny and a manually tractable number. Incremental reviews starting today by many coordinating groups in the node community would take a while to complete, maybe a few years, but with some sensible ordering heuristics like e.g. the most downloaded first, or the most suspicious names first, some value could be produced quickly. But it won't happen, package vetting isn't really a value in these communities. (And that might not really be a bad thing, at least for now...)
gkya 9y ago
Five hundred thousand packages, am I reading it right? I dont believe top ten OS package managers combined would reach that number. Either this is a typo or it's crazy.
- mbrock 9y ago
  JS is the most popular language on GitHub by far, and npm is a public site where anyone can instantly upload as many new packages as they want...
- raesene6 9y ago
  Not a typo, http://www.modulecounts.com/ http://www.modulecounts.com/ has the details. npm is adding 497/day at the moment.
  - gkya 9y ago
    This [1] is npm growth compared to anything else. God this can't be safe nor sane... [1] https://imgur.com/a/enjvR https://imgur.com/a/enjvR
    - eeZah7Ux 9y ago
      The left-pad disaster has been predicted well in advance...
      - concede_pluto 9y ago
        There's nothing especially awful about left-pad being its own package, the disaster was because a huge number of developers were betting on npm to somehow be highly available (despite being donated by its admins at no cost and with no committed SLA) rather than vendoring their deps.
        eeZah7Ux 9y ago
        Vendoring thousands of tiny libs is even worse. Trusting many lesser known, tiny libs is more risky than few, big well known ones. Also, they are not vetted and there are much more opportunities for an attacker to sneak in a backdoored lib on the edge of the dependency graph. Finally, due to vendoring there's no way to receive timely drop-in security fixes for all dependencies from a trusted source.
cdnsteve 9y ago
If there was a business/enterprise offering with extra security I'm sure they'd have a long list of people who would sign up and happily pay for it.
- raesene6 9y ago
  Those service already exit, e.g. https://www.sourceclear.com/ https://www.sourceclear.com/ whilst I hope they're doing well, I don't think they've made significant in-roads into the volume of people using open source software library repo's.
  - cdnsteve 9y ago
    It needs to be part of PyPi directly, I would have a difficult time trusting and unknown third-party.
- simon3 9y ago
  The conda package manager is free and generally feels like a professional package manager like yum or apt-get.
  - edraferi 9y ago
    Yes, Conda [0] is a package manager designed by Continuum Analytics (now Anaconda, Inc.) to support their Anaconda Distribution [1]. The distribution is free, and the Conda client is open source. However, Anaconda sells several enterprise products, including an on-premise Conda server ("Anaconda Repository"). In general, Conda does more package verification than pip, and the packages in the Anaconda distribution are more thoroughly vetted than PyPi. Conda-Forge [2] provides an escape hatch for less-vetted community code. [0] https://conda.io/docs/index.html https://conda.io/docs/index.html [1] https://www.anaconda.com/distribution/ https://www.anaconda.com/distribution/ [2] https://conda-forge.org/ https://conda-forge.org/
fha 9y ago
It always worries me when I install a well-known or large package from npm and it ends up downloading dozens of dependencies maintained by disparate and unaccountable github users.