Open sfcgeorge opened 8 years ago
What's the difference between that and this? http://bundler.io/blog/2014/08/14/bundler-may-install-gems-from-a-different-source-than-expected-cve-2013-0334.html
The instructions don't use the block syntax but are careful to specify that you must include the source as an argument and not just write a second source statement at the top of the gemfile.
Ohhhh wow! That is a vulnerability. I get it; the source is silently applied to all of them! PRs for documentation welcome; I can't get to this today but probably can by early next week.
@hut8 Yup. TLDR as Steve's blog post explains the fix didn't fix it, adding a source argument or block doesn't fully prevent lookup collisions.
Okay I'll see if i can PR if you think a doc mention is a good idea :)
I've been able to verify this affects git and github remotes too - all gemspecs in that single repo will be considered for all global gems. https://github.com/sfcgeorge/gem_clash
I'm struggling to think of a real world way this could be exploited. With RailsAssets this would only be an issue if you got hacked so someone could add a fake "rails" as you namespace everything usually, but equally they could just hack "rails-assets-jquery" so I'm not sure if this bug introduces any more risk than the trust people already have to have. I guess it's better to play safe, I'm no security expert.
See my comment on this issue in Bundler for more info and this blog post for full explanation and workaround. TLDR: Using source blocks around 3rd party gems supposedly doesn't prevent name collisions in gem resolution outside of those blocks. This might be fine if you trust 3rd party gem sources. As a popular 3rd party source I thought I'd report it to you, not to suggest you're evil, but perhaps so you can add a note to the documentation for anyone who wants to be extra safe.
Something like: