7 ms·

The security of package managers is something we're going to have to fix. Some years ago, in offices, computers were routinely infected or made unusable becaus

by tc 8y ago

The security of package managers is something we're going to have to fix. Some years ago, in offices, computers were routinely infected or made unusable because the staff were downloading and installing random screen savers from the internet. The IT staff would have to go around and scold people not to do this. If you've looked at the transitive dependency graphs of modern packages, it's hard to not feel we're doing the same thing. In the linked piece, Russ Cox notes that the cost of adding a bad dependency is the sum of the cost of each possible bad outcome times its probability. But then he speculates that for personal projects that cost may be near zero. That's unlikely. Unless developers entirely sandbox projects with untrusted dependencies from their personal data, company data, email, credentials, SSH/PGP keys, cryptocurrency wallets, etc., the cost of a bad outcome is still enormous. Even multiplied by a small probability, it has to be considered. As dependency graphs get deeper, this probability, however small, only increases. One effect of lower-cost dependencies that Russ Cox did not mention is the increasing tendency for a project's transitive dependencies to contain two or more libraries that do the same thing. When dependencies were more expensive and consequently larger, there was more pressure for an ecosystem to settle on one package for a task. Now there might be a dozen popular packages for fancy error handling and your direct and transitive dependencies might have picked any set of them. This further multiplies the task of reviewing all of the code important to your program. Linux distributions had to deal with this problem of trust long ago. It's instructive to see how much more careful they were about it. Becoming a Debian Developer involves a lengthy process of showing commitment to their values and requires meeting another member in person to show identification to be added to their cryptographic web of trust. Of course, the distributions are at the end of the day distributing software written by others, and this explosion of dependencies makes it increasingly difficult for package maintainers to provide effective review. And of course, the hassles of getting a library accepted into distributions is one reason for the popularity of tools such as Cargo, NPM, CPAN, etc. It seems that package managers, like web browsers before them, are going to have to provide some form of sandboxing. The problem is the same. We're downloading heaps of untrusted code from the internet.

LoSboccacc 8y ago
> The security of package managers is something we're going to have to fix. why the generalization? lot of package manager have been serviceable for decades, their security model based solely on verifying the maintainer identity with clients deciding which maintainer to trust. look at the amount of security advisories that are just 'malicious package' - https://www.npmjs.com/advisories https://www.npmjs.com/advisories this is of course an issue with all package manager, but it's the lack of trusted namespacing that makes it easy to fall into it. (there's scope which sound similar but the protection model of the scope name is currently unclear to me and it's optional anyway) compare to maven, where a package prefix gets registered along with a cryptographic key and only the key holder can upload to it to the central repo. sure you get malicious packages going around, but it's far easier not to fall into it because it's significantly harder to get user to download a random package off the namespaces he knows > We're downloading heaps of untrusted code from the internet. this is not something a package manager can fix, it's a culture problem. even including a gist or something off codepen is dangerous. a package manager cannot handle the 'downloading whatever' issue, it's not reasonable to put that in its thread model, because no package management maintainer can possibly guarantee that there is no malicious code in its repository and it's not its role anyway. a package manager is there to get a package to you as it was published at a specific point in time identified by its versioning, and its threat model should be people trying to publish packages under someone else name. speaking of which it took npm 4 years to prevent people to publish a package with new code under an existing version number: https://github.com/npm/npm-registry-couchapp/issues/148 https://github.com/npm/npm-registry-couchapp/issues/148 - they eventually came to sense but heck the whole node.js ecosystem gung-ho attitude is scary.
- marcus_holmes 8y ago
  > why the generalization? lot of package manager have been serviceable for decades, their security model based solely on verifying the maintainer identity with clients deciding which maintainer to trust. What happens when the maintainer of a package changes? The big problem I see happening is maintainers getting burned out and abandoning their packages, and someone else taking over. You might trust the original maintainer, but do you get notified of every change in maintainer?
faissaloo 8y ago
This right here is why Go's 'statically link everything' is going to become a big problem in the long run when old servers are running that software and no one has the source code anymore.
- reificator 8y ago
  I find that Go developers also tend to have a 'vendor everything' philosophy which significantly decreases that risk. At least the ones I meet tend to take that approach...
  - eeZah7Ux 8y ago
    If anything, it hugely increases the risk of vulnerable libraries being built into the binary and forgotten. Same with containers. Statistics clearly show the security impact.
    - cassianoleal 8y ago
      Do you have a reference to such statistics? I'd love to use them as yet another reason against vendoring dependencies when I talk to colleagues.
      - viraptor 8y ago
        https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln... Cautiously posting that link, because I'm not against vendoring. You just need a process around keeping your dependencies up to date / refreshed automatically. The ability to vendor is one thing, how you use it is another.
        cassianoleal 8y ago
        Thanks! I agree with your statement, but what I usually see in real life is that once dependencies are vendored in they never change.
deleted 8y ago
[deleted]
vinceguidry 8y ago
> The security of package managers is something we're going to have to fix. Companies that care about this already have dependency policies in place. The companies that don't care so much about security already have an approach to security problems that they will employ if a significant threat is revealed, spend time and money to fix it then. It's a herd approach. Sheep and cattle band together because there's strength in numbers and the wolves can only get one or two at a time. It's extremely effective at safeguarding most of the flock.
- thfuran 8y ago
  >Companies that care about this already have dependency policies in place. The companies that don't care so much about security already have an approach to security problems that they will employ if a significant threat is revealed, spend time and money to fix it then. I think that probably the majority of companies actually fall into a third group: Those who don't really care enough about this but also don't really have a good policy for dealing with it.
herrvogel- 8y ago
> If you've looked at the transitive dependency graphs of modern packages, it's hard to not feel we're doing the same thing. Are there any tools to do this visually. I mean visualizing the graph and interacting with it.
- robpalmer 8y ago
  Yeah, you see them all really easily here: https://anvaka.github.io/pm/#/galaxy/npm?cx=-1345&cy=-7006&cz=-6553&lx=0.6217&ly=-0.6459&lz=0.3098&lw=0.3168&ml=150&s=1.75&l=1&v=2018-11-02T00-00-00Z&_k=z9dc6f https://anvaka.github.io/pm/#/galaxy/npm?cx=-1345&cy=-7006&c...
  - DDR0 8y ago
    Dang, that's _beautiful_.
jancsika 8y ago
> It's instructive to see how much more careful they were about it. "Much more careful" would have been a requirement to consult upstream on all patches that are beyond the maintainer's level of expertise. Especially so for all patches that potentially affect the functioning of cryptographic libraries. Debian has had a catastrophe to show the need for such a guideline. Do they currently have such a guideline? If not it's difficult to see the key parties as little more than security theatre. Edit: clarification
debiandev 8y ago
> Becoming a Debian Developer involves a lengthy process of showing commitment to their values and requires meeting another member in person to show identification to be added to their cryptographic web of trust At the very least. More often people receive mentoring for months and meet in person. > this explosion of dependencies makes it increasingly difficult for package maintainers to provide effective review It makes packaging extremely time consuming and that's why a lot of things in Go and javascript are not packaged. The project cares about security and compliance to licensing.
int_19h 8y ago
> ... the increasing tendency for a project's transitive dependencies to contain two or more libraries that do the same thing. When dependencies were more expensive and consequently larger, there was more pressure for an ecosystem to settle on one package for a task. Now there might be a dozen popular packages for fancy error handling and your direct and transitive dependencies might have picked any set of them. It's not just a security problem. It also hampers composition, because when two libraries talk about the same concept in different "terms"/objects/APIs (because they rely on two different other libraries to wrap it), you have to write a bridge to make them talk to each other. That's why large standard libraries are beneficial - they define the common vocabulary that third-party libraries can then use in their API surface to allow them to interoperate smoothly.
pier25 8y ago
After using Go and Dart on a number of projects and using very few dependencies (compared to JavaScript projects) I'd say a good starting point is having a great standard library. For example, it's a bit ridiculous that in 2019 we cannot decode a JWT using a simple browser API, still need Moment for time and date operations, there is no observable type (a 4 year old proposal is still in draft stage), and still no native data-binding. The TC39 is moving too slowly and that's one of the reasons why NPM is so popular.
- ummonk 8y ago
  I mean, even all of those examples you listed aren't as crazy as the fact that you need a library to parse the cookie string and deal with individual cookies...
- acutesoftware 8y ago
  > I'd say a good starting point is having a great standard library. True, and at this stage, I am also playing with Javascript dates and timezones and I would be happy with a mediocre standard library.
ndnxhs 8y ago
I'm a big fan of kitchen sink frameworks for this reason. Whenever I want to do something in JS the answer is to install a package for it. When I want to do something in rails the answer is its built in. I have installed far far fewer packages for my back end than the frontend and the back end is vastly more complex
- pjmlp 8y ago
  Same here. Turbo Vision, Clipper, OWL, MFC, Forms, JEE, ASP.NET, Liferay, Sitecore,... I don't have patient to play hunt the dependency game, followed by get all of them to play well together.
_pmf_ 8y ago
> The security of package managers is something we're going to have to fix. Inclusiveness and the need for Jeff Freshman and Jane Sophomore to have a list of 126 GitHub repos before beginning their application process for an intern job is at odds with having vetted entities as package providers. When I was developing Eclipse RCP products, I had three or five entities that provided signed packages I used as dependencies. Plus: with npm, you even have tooling dependencies, so the former theoretical threat of a malicious compiler injecting malware is now the sad reality[0]. I'm not claiming the "old way" is secure, but the "new way" is insecure by design and by policy (inclusiveness, gatekeeping as fireable offense). [0] I have tooling dependencies in Gradle and Maven too, but again, these are by large vendors and not by some random resume padding GitHub user.
gousiosg 8y ago
Here is some recent research where we are trying to solve the security and update issues in Rust/Cargo: https://pure.tudelft.nl/portal/files/46926997/main2.pdf https://pure.tudelft.nl/portal/files/46926997/main2.pdf TLDR: it boils down to analysing dependencies at the level of the callgraph; but building those callgraphs isn't easy. The benefit in the security use case is ~3x increased accuracy when identifying vulnerable packages (by eliminating false positives).

by tc 8y ago

LoSboccacc 8y ago

> The security of package managers is something we're going to have to fix. why the generalization? lot of package manager have been serviceable for decades, their security model based solely on verifying the maintainer identity with clients deciding which maintainer to trust. look at the amount of security advisories that are just 'malicious package' - https://www.npmjs.com/advisories https://www.npmjs.com/advisories this is of course an issue with all package manager, but it's the lack of trusted namespacing that makes it easy to fall into it. (there's scope which sound similar but the protection model of the scope name is currently unclear to me and it's optional anyway) compare to maven, where a package prefix gets registered along with a cryptographic key and only the key holder can upload to it to the central repo. sure you get malicious packages going around, but it's far easier not to fall into it because it's significantly harder to get user to download a random package off the namespaces he knows > We're downloading heaps of untrusted code from the internet. this is not something a package manager can fix, it's a culture problem. even including a gist or something off codepen is dangerous. a package manager cannot handle the 'downloading whatever' issue, it's not reasonable to put that in its thread model, because no package management maintainer can possibly guarantee that there is no malicious code in its repository and it's not its role anyway. a package manager is there to get a package to you as it was published at a specific point in time identified by its versioning, and its threat model should be people trying to publish packages under someone else name. speaking of which it took npm 4 years to prevent people to publish a package with new code under an existing version number: https://github.com/npm/npm-registry-couchapp/issues/148 https://github.com/npm/npm-registry-couchapp/issues/148 - they eventually came to sense but heck the whole node.js ecosystem gung-ho attitude is scary.

marcus_holmes 8y ago
> why the generalization? lot of package manager have been serviceable for decades, their security model based solely on verifying the maintainer identity with clients deciding which maintainer to trust. What happens when the maintainer of a package changes? The big problem I see happening is maintainers getting burned out and abandoning their packages, and someone else taking over. You might trust the original maintainer, but do you get notified of every change in maintainer?

faissaloo 8y ago

This right here is why Go's 'statically link everything' is going to become a big problem in the long run when old servers are running that software and no one has the source code anymore.

reificator 8y ago
I find that Go developers also tend to have a 'vendor everything' philosophy which significantly decreases that risk. At least the ones I meet tend to take that approach...
- eeZah7Ux 8y ago
  If anything, it hugely increases the risk of vulnerable libraries being built into the binary and forgotten. Same with containers. Statistics clearly show the security impact.
  - cassianoleal 8y ago
    Do you have a reference to such statistics? I'd love to use them as yet another reason against vendoring dependencies when I talk to colleagues.
    - viraptor 8y ago
      https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln... Cautiously posting that link, because I'm not against vendoring. You just need a process around keeping your dependencies up to date / refreshed automatically. The ability to vendor is one thing, how you use it is another.
      - cassianoleal 8y ago
        Thanks! I agree with your statement, but what I usually see in real life is that once dependencies are vendored in they never change.

deleted 8y ago

[deleted]

vinceguidry 8y ago

> The security of package managers is something we're going to have to fix. Companies that care about this already have dependency policies in place. The companies that don't care so much about security already have an approach to security problems that they will employ if a significant threat is revealed, spend time and money to fix it then. It's a herd approach. Sheep and cattle band together because there's strength in numbers and the wolves can only get one or two at a time. It's extremely effective at safeguarding most of the flock.

thfuran 8y ago
>Companies that care about this already have dependency policies in place. The companies that don't care so much about security already have an approach to security problems that they will employ if a significant threat is revealed, spend time and money to fix it then. I think that probably the majority of companies actually fall into a third group: Those who don't really care enough about this but also don't really have a good policy for dealing with it.

herrvogel- 8y ago

> If you've looked at the transitive dependency graphs of modern packages, it's hard to not feel we're doing the same thing. Are there any tools to do this visually. I mean visualizing the graph and interacting with it.

robpalmer 8y ago
Yeah, you see them all really easily here: https://anvaka.github.io/pm/#/galaxy/npm?cx=-1345&cy=-7006&cz=-6553&lx=0.6217&ly=-0.6459&lz=0.3098&lw=0.3168&ml=150&s=1.75&l=1&v=2018-11-02T00-00-00Z&_k=z9dc6f https://anvaka.github.io/pm/#/galaxy/npm?cx=-1345&cy=-7006&c...
- DDR0 8y ago
  Dang, that's _beautiful_.

jancsika 8y ago

> It's instructive to see how much more careful they were about it. "Much more careful" would have been a requirement to consult upstream on all patches that are beyond the maintainer's level of expertise. Especially so for all patches that potentially affect the functioning of cryptographic libraries. Debian has had a catastrophe to show the need for such a guideline. Do they currently have such a guideline? If not it's difficult to see the key parties as little more than security theatre. Edit: clarification

debiandev 8y ago

> Becoming a Debian Developer involves a lengthy process of showing commitment to their values and requires meeting another member in person to show identification to be added to their cryptographic web of trust At the very least. More often people receive mentoring for months and meet in person. > this explosion of dependencies makes it increasingly difficult for package maintainers to provide effective review It makes packaging extremely time consuming and that's why a lot of things in Go and javascript are not packaged. The project cares about security and compliance to licensing.

int_19h 8y ago

> ... the increasing tendency for a project's transitive dependencies to contain two or more libraries that do the same thing. When dependencies were more expensive and consequently larger, there was more pressure for an ecosystem to settle on one package for a task. Now there might be a dozen popular packages for fancy error handling and your direct and transitive dependencies might have picked any set of them. It's not just a security problem. It also hampers composition, because when two libraries talk about the same concept in different "terms"/objects/APIs (because they rely on two different other libraries to wrap it), you have to write a bridge to make them talk to each other. That's why large standard libraries are beneficial - they define the common vocabulary that third-party libraries can then use in their API surface to allow them to interoperate smoothly.

pier25 8y ago

After using Go and Dart on a number of projects and using very few dependencies (compared to JavaScript projects) I'd say a good starting point is having a great standard library. For example, it's a bit ridiculous that in 2019 we cannot decode a JWT using a simple browser API, still need Moment for time and date operations, there is no observable type (a 4 year old proposal is still in draft stage), and still no native data-binding. The TC39 is moving too slowly and that's one of the reasons why NPM is so popular.

ummonk 8y ago
I mean, even all of those examples you listed aren't as crazy as the fact that you need a library to parse the cookie string and deal with individual cookies...
acutesoftware 8y ago
> I'd say a good starting point is having a great standard library. True, and at this stage, I am also playing with Javascript dates and timezones and I would be happy with a mediocre standard library.

ndnxhs 8y ago

I'm a big fan of kitchen sink frameworks for this reason. Whenever I want to do something in JS the answer is to install a package for it. When I want to do something in rails the answer is its built in. I have installed far far fewer packages for my back end than the frontend and the back end is vastly more complex

pjmlp 8y ago
Same here. Turbo Vision, Clipper, OWL, MFC, Forms, JEE, ASP.NET, Liferay, Sitecore,... I don't have patient to play hunt the dependency game, followed by get all of them to play well together.

_pmf_ 8y ago

> The security of package managers is something we're going to have to fix. Inclusiveness and the need for Jeff Freshman and Jane Sophomore to have a list of 126 GitHub repos before beginning their application process for an intern job is at odds with having vetted entities as package providers. When I was developing Eclipse RCP products, I had three or five entities that provided signed packages I used as dependencies. Plus: with npm, you even have tooling dependencies, so the former theoretical threat of a malicious compiler injecting malware is now the sad reality[0]. I'm not claiming the "old way" is secure, but the "new way" is insecure by design and by policy (inclusiveness, gatekeeping as fireable offense). [0] I have tooling dependencies in Gradle and Maven too, but again, these are by large vendors and not by some random resume padding GitHub user.

gousiosg 8y ago

Here is some recent research where we are trying to solve the security and update issues in Rust/Cargo: https://pure.tudelft.nl/portal/files/46926997/main2.pdf https://pure.tudelft.nl/portal/files/46926997/main2.pdf TLDR: it boils down to analysing dependencies at the level of the callgraph; but building those callgraphs isn't easy. The benefit in the security use case is ~3x increased accuracy when identifying vulnerable packages (by eliminating false positives).