Em 22-01-2014 21:38, sam / kottlerdevelopment.com escreveu:
> Issue #9439 has been updated by Sam Kottler.
>
>
> Rodrigo Rosenfeld Rosas wrote:
>> Em 22-01-2014 16:39, luislavena / gmail.com escreveu:
>>   > Issue #9439 has been updated by Luis Lavena.
>>   >
>>   >
>>   > Shyouhei Urabe wrote:
>>   >> Very true.  I have no idea on why RubyGems use https and not other tools.  Any pointers?
>>   > AFAIK is to avoid MITM attacks and such, since if signatures are also stored along packages, how can you verify that the packages are not altered?
>>   
>>   I've always been curious about that, specially because the introduction
>>   of https://rubygems.org slowed down our deploys considerably and it's
>>   way slower to run bundler over the https version when compared to the
>>   regular http version.
>>   
>>   If the only concern is about MITM attacks and if the reason for the much
>>   slower gems downloading is because they are being served through an
>>   HTTPS connection, then it would probably be much faster if we only got
>>   the list of gems signature over an HTTPS connection, That way we'd be
>>   able to download the gems over regular http and then calculate the
>>   checksum and verify against the list of checksums downloaded from the
>>   secure connection. Or we could download the public key that signed all
>>   gems (in the case rubygems.org itself signed all gems) from a secure
>>   location (https) and perform all checks locally. Wouldn't that work and
>>   be much faster than the current alternative?
> I'm one of the maintainers of rubygems.org and bundler and haven't ever heard this complaint before. Can you email me with more info about your environment? https should not be notably slower than http. And yes, your solution works, but the problem is that we currently don't have a mechanism for matching checksums to binaries AFAIK. So while possible in the theoretical sense, it's not as straight forward as you make it seem.

I've sent the difference in total time (7m for https vs 5m for http) off 
the list, but there's another thing to consider in my opinion: the use 
of proxy servers, like Squid.

As far as I understand, proxy servers can't cache https data. So, if 
you're behind a proxy, either because you work inside a corporation (or 
with other coworkers) or if you want to test your Vagrant recipes and 
avoid re-downloading the same gems over and over you could take 
advantage of the proxy cache if the gems themselves are served through 
regular http.

This is something to consider, don't you think?