Access rubygems.org via https by default when using :rubygems in Gemfile #1585
Conversation
Access rubygems.org via https by default when using :rubygems in Gemfile
|
Nice catch. |
|
I'm sorry, but we can't make this change until Bundler 2.0 at the earliest. SemVer means we can't change 1.0 behaviors, we can only add new features on top until 2.0. Thanks for the patch, though! On Dec 12, 2011, at 6:59 AM, Steve Agallocoreply@reply.github.com wrote:
|
|
Hmmm, I thought about SemVer when pulling this but I didn't think it was relevant because it was backward compatible. Does this really count as a breaking change? |
|
It will change all existing Gemfiles that contain :rubygems to suddenly start using HTTPS. For users on machines with bad (or old) SSL CA cert bundles, that could stop Bundler from working entirely. It's definitely at least potentially breaking. On Dec 12, 2011, at 7:36 AM, Erik Michaels-Oberreply@reply.github.com wrote:
|
|
PS: I'm happy to revert the commit if necessary. I'd just like to fully understand why it's necessary first. |
|
Okay, I'll revert it. |
|
Is there a 2.0 branch or milestone where we can put stuff like this so we don't forget about it? |
|
Cool. Possibly we should start collecting these changes in a label (or even a branch) for 2.0? /cc @hone On Dec 12, 2011, at 7:40 AM, Erik Michaels-Oberreply@reply.github.com wrote:
|
|
Let's go with milestone for now and we can figure out if a branch is better later. Thanks! On Dec 12, 2011, at 7:41 AM, Erik Michaels-Oberreply@reply.github.com wrote:
|
|
Reverted in 7c7282f. |
|
Thanks for the discussion here, I can see why this creates a SemVer issue. I guess I have some Gemfiles to update 🤘 |
|
I would be against making a 2.0 at all for stuff like this. Ideally, we would be able to avoid making a breaking semver version of bundler unless we had a darn good reason for it, and I don't think this counts. That said, we could potentially print a warning when using HTTP that "you really ought to be using HTTPS". Not sure how new warnings affect SemVer :p |
|
I think that's a natural stance to take. The problem is that this change would break bundler on many, many production machines that have old CA cert bundles installed. The only way to keep bundler working on those machines is to not change the default symbol to use SSL. Since that makes this a breaking change of current functionality, 2.0 seems like the minimum version possible. On Dec 13, 2011, at 8:44 AM, Yehuda Katzreply@reply.github.com wrote:
|
|
I think Yehuda is arguing for never releasing 2.0. I guess that's a natural reaction after going through the outcry after breaking compatibility between 0.8 and 0.9 and 0.9 and 1.0. |
|
Would the possibility exist of shipping a vendored cert? Airbrake recently took that approach. That obviously comes with some other implications. May be more trouble than it's worth. Just a thought. |
|
@spagalloco I think that would somewhat defeat the purpose of using SSL in the first place. |
|
If you're using Bundler to get your gems, you already have to trust it to get them from rubygems.org. Including the cert would just mean Bundler could be sure that it was talking to the real rubygems.org and not a mitm attack. That said, I prefer people to manage their own security stuff, because there rarely seems to be a one-size-fits-all approach that succeeds. If we can avoid shipping the cert, I would rather do that. On Dec 13, 2011, at 11:14 AM, Henrik Hodnereply@reply.github.com wrote:
|
|
@indirect agreed. Airbrake obviously had an entirely different use case. I'm probably beating a dead horse at this point, so I'll drop it. Thanks. :) |
if https is the best way to access rubygems.org then it should be default everywhere including in examples on the man page
… in Gemfile." This reverts commit cd93968 because it violates Semantic Versioning. See http://semver.org/ and rubygems#1585
I'm partial to using
source :rubygemssyntax in my Gemfile to denote a source but noticed that it was using http instead of https, this brings the https changes in sync with those made in #1562 and #1522