4 ms·

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.

by geoka9 14y ago

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.

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.

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