5 ms·

This one annoyed me recently. $ bundle The source :rubygems is deprecated because HTTP requests are insecure. Please change your source to 'https://rubyg

by mdavidn 14y ago

This one annoyed me recently. $ bundle The source :rubygems is deprecated because HTTP requests are insecure. Please change your source to 'https://rubygems.org' if possible, or 'http://rubygems.org' if not. Why can't Bundler just use the new URL? Or, better yet, assume https://rubygems.org https://rubygems.org unless I specify sources in my Gemfile?

geoka9 14y ago
Maybe because it wants you to be in control? What they probably could do, though, is a 302 redirect to https. But that's frown upon by some, too.
- mdavidn 14y ago
  I only want to be in control when my use case differs from the common case. I would wager that at least 95% of Gemfiles could source https://rubygems.org https://rubygems.org implicitly and automatically.
  - steveklabnik 14y ago
    You can't guarantee that Ruby has OpenSSL support compiled in, it's not required.
    - vidarh 14y ago
      But you can check, and fail if the user specifies https and it's not present, and give a warning if the user doesn't specify anything or specifies http and OpenSSL is not present. I still think mdavidn is probably right that 95% or similarly high number has OpenSSL available, and it makes little sense to inconvenience all of those users when you can inconvenience "just" the few who don't instead.
- tinco 14y ago
  It's not just frowned upon. Having a 302 redirect is almost as insecure as not upgrading to https at all. In browsers this is sort of acceptable because they let you visually confirm that you've been upgraded to https, and are now securely connected to the right server. In a text mode app that does the connection behind the scenes and fully automatically, there's no such confirmation or even intervention, so there's no perceptible difference between http and http 302 to https. Ruby (on Rails) values convention over configuration. It should have made https obligatory per default and overrideable with a flag per this guideline.
  - vidarh 14y ago
    > In a text mode app that does the connection behind the scenes and fully automatically, there's no such confirmation or even intervention, so there's no perceptible difference between http and http 302 to https. This assumes the client doesn't kick up a fuzz. The entire point is Bundler now does kick up a fuzz. But it could also be made to follow any redirect first, and only kick up a fuzz if the final resource is not https.
    - ptomato 14y ago
      That really doesn't provide any security advantage over just using http. The point of https is to prevent mitm and in this case there's nothing preventing somebody from mitming the original http connection and redirecting to an evil https site.
      - singlow 14y ago
        It could only allow redirect to the same domain and complain if a cert check failed.
steveklabnik 14y ago
SemVer means you can't break backwards compatibility. Everyone loves not breaking compatibility until they want a breaking change.
- dragonwriter 14y ago
  > SemVer means you can't break backwards compatibility. No, SemVer means you increment major version numbers if, and only if, you break backwards compatibility.
  - steveklabnik 14y ago
    Right, and therefore, if you don't want to increment the major version number, you can't break compatibility. I am really not going to get into an argument about this, you're being ridiculous.
    - dragonwriter 14y ago
      > Right, and therefore, if you don't want to increment the major version number, you can't break compatibility. That's true, but both silly and not what you said before. There's no good reason to care about version numbers in and of themselves, if you care about them at all, its because of their semantics: using SemVer doesn't make you not want to break backward compatibility, not wanting to break backward compatibility is independent of the use of SemVer. Of course, if you don't want to break backward compatibility, you won't end up bumping the major version number under SemVer, but you've got the whole direction of cause-and-effect wired backward when you say that SemVer is the reason not to break backward compatibility.
      - dasil003 14y ago
        Okay let me spell it out for you: No one wants a major version bump in Bundler in order to change the primary rubygems URL because historically there is a lot of potential pain in Bundler updates, and so you better be getting something new that's worth the pain, not just a superficial change that happens to break compatibility only as a technicality.
Karunamon 14y ago
This may be a terrifically silly question, but here goes anyways: What sensitive data are people passing back and forth to rubygems of all places that needs encryption? Especially in the context of a bundle where you're more likely than not pulling down or updating gems (from a public repository, which contains no sensitive data)? And this need is apparently so pressing that it should be complained about to the user?
- acdha 14y ago
  You're installing code to run using your privileges. Don't you want protection against MITM attacks?
  - Karunamon 14y ago
    And there's the confirmation that it was a silly question. I've been on a plane all morning and am in no condition to be parsing the topics here :)
  - sneak 14y ago
    That's why everyone who runs a package repository who isn't a shitdick SIGNS THEIR FUCKING PACKAGES. It protects against tampering on the mirrors, too, with the added bonus that you don't need SSL. Oh, wait, this is rubyland. Nevermind.
- ville 14y ago
  Confidentiality is not the only feature of HTTPS. Using HTTPS can also protect from simplest man-in-the-middle attacks by validating the certificate, thus improving data integrity.

by mdavidn 14y ago

geoka9 14y ago

Maybe because it wants you to be in control? What they probably could do, though, is a 302 redirect to https. But that's frown upon by some, too.

mdavidn 14y ago
I only want to be in control when my use case differs from the common case. I would wager that at least 95% of Gemfiles could source https://rubygems.org https://rubygems.org implicitly and automatically.
- steveklabnik 14y ago
  You can't guarantee that Ruby has OpenSSL support compiled in, it's not required.
  - vidarh 14y ago
    But you can check, and fail if the user specifies https and it's not present, and give a warning if the user doesn't specify anything or specifies http and OpenSSL is not present. I still think mdavidn is probably right that 95% or similarly high number has OpenSSL available, and it makes little sense to inconvenience all of those users when you can inconvenience "just" the few who don't instead.
tinco 14y ago
It's not just frowned upon. Having a 302 redirect is almost as insecure as not upgrading to https at all. In browsers this is sort of acceptable because they let you visually confirm that you've been upgraded to https, and are now securely connected to the right server. In a text mode app that does the connection behind the scenes and fully automatically, there's no such confirmation or even intervention, so there's no perceptible difference between http and http 302 to https. Ruby (on Rails) values convention over configuration. It should have made https obligatory per default and overrideable with a flag per this guideline.
- vidarh 14y ago
  > In a text mode app that does the connection behind the scenes and fully automatically, there's no such confirmation or even intervention, so there's no perceptible difference between http and http 302 to https. This assumes the client doesn't kick up a fuzz. The entire point is Bundler now does kick up a fuzz. But it could also be made to follow any redirect first, and only kick up a fuzz if the final resource is not https.
  - ptomato 14y ago
    That really doesn't provide any security advantage over just using http. The point of https is to prevent mitm and in this case there's nothing preventing somebody from mitming the original http connection and redirecting to an evil https site.
    - singlow 14y ago
      It could only allow redirect to the same domain and complain if a cert check failed.

steveklabnik 14y ago

SemVer means you can't break backwards compatibility. Everyone loves not breaking compatibility until they want a breaking change.

dragonwriter 14y ago
> SemVer means you can't break backwards compatibility. No, SemVer means you increment major version numbers if, and only if, you break backwards compatibility.
- steveklabnik 14y ago
  Right, and therefore, if you don't want to increment the major version number, you can't break compatibility. I am really not going to get into an argument about this, you're being ridiculous.
  - dragonwriter 14y ago
    > Right, and therefore, if you don't want to increment the major version number, you can't break compatibility. That's true, but both silly and not what you said before. There's no good reason to care about version numbers in and of themselves, if you care about them at all, its because of their semantics: using SemVer doesn't make you not want to break backward compatibility, not wanting to break backward compatibility is independent of the use of SemVer. Of course, if you don't want to break backward compatibility, you won't end up bumping the major version number under SemVer, but you've got the whole direction of cause-and-effect wired backward when you say that SemVer is the reason not to break backward compatibility.
    - dasil003 14y ago
      Okay let me spell it out for you: No one wants a major version bump in Bundler in order to change the primary rubygems URL because historically there is a lot of potential pain in Bundler updates, and so you better be getting something new that's worth the pain, not just a superficial change that happens to break compatibility only as a technicality.

Karunamon 14y ago

This may be a terrifically silly question, but here goes anyways: What sensitive data are people passing back and forth to rubygems of all places that needs encryption? Especially in the context of a bundle where you're more likely than not pulling down or updating gems (from a public repository, which contains no sensitive data)? And this need is apparently so pressing that it should be complained about to the user?

acdha 14y ago
You're installing code to run using your privileges. Don't you want protection against MITM attacks?
- Karunamon 14y ago
  And there's the confirmation that it was a silly question. I've been on a plane all morning and am in no condition to be parsing the topics here :)
- sneak 14y ago
  That's why everyone who runs a package repository who isn't a shitdick SIGNS THEIR FUCKING PACKAGES. It protects against tampering on the mirrors, too, with the added bonus that you don't need SSL. Oh, wait, this is rubyland. Nevermind.
ville 14y ago
Confidentiality is not the only feature of HTTPS. Using HTTPS can also protect from simplest man-in-the-middle attacks by validating the certificate, thus improving data integrity.