Mercurial failing on TLSv1.2 repos, but I wrote a patch
Matt Mackall
mpm at selenic.com
Wed Jul 22 16:04:28 CDT 2015
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.
More information about the Mercurial-devel
mailing list