(I also don't think it's true that the attacker has a "small window of time"—as soon as they get a single RCE, it's over, if they're running on a normal dev machine then they can daemonize into the background, add persistence, and snoop events over time. CI systems are obviously less vulnerable to this by nature.)
If you know your computer was compromised. Shut down and reinstall from a backup, you don’t try and clean it.
Edit: I’m assuming the attacker would be replacing a dependency with an empty repo since they don’t know the actual source code. If they know the interface the dependency is supposed to provide, it could spread across the entire organization before anyone noticed.
> I would hope most SSH keys are password-encrypted
TBH, these are probably weak passwords for convenience.
However, this section is concerning:
> The presence of a source block in a Gemfile also makes that source available as a possible global source for any other gems which do not specify explicit sources. Thus, when defining source blocks, it is recommended that you also ensure all other gems in the Gemfile are using explicit sources, either via source blocks or :source directives on individual gems.
Yikes! This is yet another easy footgun for people to reintroduce this issue
That is, given a Gemfile.lock like, e.g.
How would Bundler ever try and download the `appraisal` gem from RubyGems?The Gemfile section is more explicable. While newer Gemfiles look like this:
Older Gemfiles apparently looked like the following: 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?