Access rubygems.org via https by default when using :rubygems in Gemfile #1585

Merged
merged 1 commit into from Dec 12, 2011

Conversation

Projects
None yet
5 participants
Contributor

stve commented Dec 12, 2011

I'm partial to using source :rubygems syntax 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

sferik added a commit that referenced this pull request Dec 12, 2011

Merge pull request #1585 from spagalloco/https
Access rubygems.org via https by default when using :rubygems in Gemfile

@sferik sferik merged commit 3562da1 into bundler:master Dec 12, 2011

Member

sferik commented Dec 12, 2011

Nice catch.

Owner

indirect commented Dec 12, 2011

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:

I'm partial to using source :rubygems syntax 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

You can merge this Pull Request by running:

git pull https://github.com/spagalloco/bundler https

Or you can view, comment on it, or merge it online at:

carlhuda#1585

-- Commit Summary --

  • Access rubygems.org via https by default when using :rubygems in Gemfile.

-- File Changes --

M lib/bundler/dsl.rb (2)

-- Patch Links --

https://github.com/carlhuda/bundler/pull/1585.patch
https://github.com/carlhuda/bundler/pull/1585.diff


Reply to this email directly or view it on GitHub:
carlhuda#1585

Member

sferik commented Dec 12, 2011

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?

Owner

indirect commented Dec 12, 2011

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:

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?


Reply to this email directly or view it on GitHub:
carlhuda#1585 (comment)

Member

sferik commented Dec 12, 2011

PS: I'm happy to revert the commit if necessary. I'd just like to fully understand why it's necessary first.

Member

sferik commented Dec 12, 2011

Okay, I'll revert it.

Member

sferik commented Dec 12, 2011

Is there a 2.0 branch or milestone where we can put stuff like this so we don't forget about it?

Owner

indirect commented Dec 12, 2011

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:

Okay, I'll revert it.


Reply to this email directly or view it on GitHub:
carlhuda#1585 (comment)

Owner

indirect commented Dec 12, 2011

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:

Is there a 2.0 branch or milestone where we can put stuff like this so we don't forget about it?


Reply to this email directly or view it on GitHub:
carlhuda#1585 (comment)

Member

sferik commented Dec 12, 2011

Reverted in 7c7282f.

Contributor

stve commented Dec 12, 2011

Thanks for the discussion here, I can see why this creates a SemVer issue. I guess I have some Gemfiles to update 🤘

Contributor

wycats commented Dec 13, 2011

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

Owner

indirect commented Dec 13, 2011

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 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.


Reply to this email directly or view it on GitHub:
carlhuda#1585 (comment)

Member

sferik commented Dec 13, 2011

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.

Contributor

stve commented Dec 13, 2011

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.

Owner

indirect commented Dec 13, 2011

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:

@spagalloco I think that would somewhat defeat the purpose of using SSL in the first place.


Reply to this email directly or view it on GitHub:
carlhuda#1585 (comment)

Contributor

stve commented Dec 13, 2011

@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. :)

stve referenced this pull request Feb 14, 2013

use https://rubygems.org everywhere
if https is the best way to access rubygems.org
then it should be default everywhere
including in examples on the man page

hsbt pushed a commit to hsbt/bundler that referenced this pull request Feb 9, 2014

Revert "Access rubygems.org via https by default when using :rubygems…
… in Gemfile."

This reverts commit cd93968 because it
violates Semantic Versioning. See http://semver.org/ and
bundler#1585
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment