Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

But will anything change in the minds and hearts of developers?

But the broad issue will never be resolved. The entire foundation of society is built around some trust. What has proven to work is that we trust actors who are identifiable and have something to lose. This goes with everything from your bank, to government, to name brands, to your local restaurant.

Nix package managers/repositories have a level of scrutiny to get into, and highly dedicated people in charge of. Random github repos (or npm packages) are extremely low effort/risk to set up.

Of course the former can be abused, but the incentives are at least in its favor to likely be more trustworthy. And we have to make assumptions of trust everytime we sit down in our chair or turn on our computer, or plug in a space heater. We will never get around trust, but there are differences in levels of trust and trustworthiness.

The article mentions that RubyGems is vulnerable to this, and that Shopify in particular downloaded and ran a gem named "shopify-cloud", but I'm curious as to how this is possible given a "normal" bundler pure-lockfile setup, or more generally the source-block directives I've seen in most Gemfiles.

That is, given a Gemfile.lock like, e.g.

    GIT
      remote: https://github.com/thoughtbot/appraisal
      revision: 5675d17a95cfe904cc4b19dfd3f1f4c6d54d3502
      specs:
        appraisal (2.1.0)
          bundler
          rake
          thor (>= 0.14.0)

How would Bundler ever try and download the `appraisal` gem from RubyGems?

The Gemfile section is more explicable. While newer Gemfiles look like this:

    source "http://our.own.gem.repo.com/the/path/to/it" do
      gem 'gemfromourrepo'
    end
    # or
    gem 'gemfromourrepo', source: "http://our.own.gem.repo.com/the/path/to/it"

Older Gemfiles apparently looked like the following:

    source 'https://rubygems.org'
    source 'http://our.own.gem.repo.com/the/path/to/it'

    gem 'gemfromrubygems1'  
    gem 'gemfromrubygems2'
    gem 'gemfromourrepo'

Which seems obviously vulnerable to the dependency confusion issue mentioned.

So is the understanding that Shopify's CI systems were running `bundle upgrade` or another non-lockfile operation? (possibly as a greenkeeper-like cron job?) Or is `--pure-lockfile` itself more subtly vulerable?

The real solution is to design and build software components that can be finished, so they can be ruthlessly vetted - rather than the endless churn of updates.

Isn't it considered best practice to be secure by default? Wasn't that big fiasco with MongoDB? Why should PyPI, RubyGems, or npm be any different? I'm sure there is some reason but I'd expect them to all pull private repos before public.

Maybe the bug wasn't explained correctly but if it prefers public over private that seems like a bug.

OTOH, it certainly is an issue that if you forget and happen to test some code without being configured to have the private package server as your default then you'd get public repos.

Maybe instead of named packages companies should be using private URLs for packages. That way you always get what you ask for?