Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
CVE-2016-7954 secondary sources #5051
Hi there. No one has contacted the Bundler team in any way regarding this vulnerability yet. We believe that we have already fixed the issue in an upcoming release, but there is no way to tell, since no one has bothered to give us the details of the supposed CVE.
referenced this issue
Oct 6, 2016
What I could find:
Could this be a security issue in real world production environments? One thing that springs to mind is Rails Assets so I've opened a feeler issue there. Of course GitHub and Bitbucket inline sources are common too.
If it could be a real security issue, and assuming a fix can't be backported, should a warning be added suggesting the no top level source using only blocks workaround?
Was the team contacted, what was the actual response? How does RubyTogether fit into this, would additional funds from concerned parties help? Does RubyTogether prioritise security fixes (I don't see it on the site)?
I'm just collating info that may or may not be helpful, not trying to stir alarm or anything. You all do a great job, and it's really appreciated
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
However I'm struggling to think of a real world way this could be exploited. It would be easier for a rogue gem author to add malicious code to their own gem than add a second fake gem for "rails" or whatever.