Mercurial failing on TLSv1.2 repos, but I wrote a patch

[Matt Mackall]

On Wed, 2015-07-22 at 10:19 -0700, Gregory Szorc wrote:
> 
> > On Jul 20, 2015, at 14:33, Matt Mackall <mpm at selenic.com> wrote:
> > 
> >> On Mon, 2015-07-20 at 21:01 +0000, Warren Melnick wrote:
> >> I am using 2.6.  It hits that line which says TLSv1 (line 55, as
> >> highlighted in your example).  TLSv1 is NOT TLSv1.x, it is TLSv1.0
> >> only.  The only one that gives the choice of TLS is SSLv23, it is just
> >> very poorly named.  See the chart here:
> >> https://docs.python.org/2/library/ssl.html#socket-creation
> > 
> > That was indeed the gist of my first message?
> 
> The TLSv1 flag for Pythons < 2.7.9 will use TLSv1.0 and *only* TLSv1.0. Whereas our Python >=2.7.9 code path will use will use *any* version of TLS courtesy of SSLv23 + OP constants to remove busted protocols.
> 
> If a server is speaking TLSv1.1 or above but not TLSv1.0, Mercurial on <2.7.9 will refuse to speak to it. That's not ideal. But it's the corner Python's busted crypto has painted us in.
> 
> I wonder if we could have the <2.7.9 code path try to import pyOpenSSL so we can give those users TLS > 1.0?

Another possibility would be to use the default mode and then check the
resultant socket for a sensible answer. No idea if this is actually
workable though.

Some numbers:

https://securitypitfalls.wordpress.com/2014/05/19/tls-1-2-adoption-half-way-mark-reached/
https://www.trustworthyinternet.org/ssl-pulse/

TLSv1.0 is at 99.5% availability so I think we should probably just
encourage people to do one of:

a) upgrade to Py2.7.9 on their clients
b) enable v1.0 on their server

-- 
Mathematics is the supreme nostalgia of our time.