Cannot pull/push to https server with self-signed certificate

Mads Kiilerich mads at kiilerich.com
Fri Jan 7 13:14:03 CST 2011


[moved from mercurial to -devel]

On 01/07/2011 03:31 AM, Adrian Buehlmann wrote:
> On 2011-01-07 03:18, Mads Kiilerich wrote:
>> Adrian Buehlmann wrote, On 01/07/2011 03:15 AM:
>>> On 2011-01-07 02:53, Mads Kiilerich wrote:
>>>> Brian Sullivan wrote, On 01/06/2011 07:31 PM:
>>>>> This discussion actually started as a bug reported about TortoiseHG
>>>>> here:
>>>>> https://bitbucket.org/tortoisehg/thg/issue/63/cannot-pull-push-to-https-server-with-self
>>>>>
>>>>>
>>>>> I installed the latest version of TortoiseHg (1.1.8) on a new Windows
>>>>> machine with no previous TortoiseHg or Mercurial installation.  We're
>>>>> running our shared Mercurial server on Windows Server 2008 R2 under
>>>>> IIS 7.5 with SSL using a self-signed certificate.  Things have been
>>>>> running just fine for other users at our company on previous versions
>>>>> of TortoiseHg.
>>>>>
>>>>> When I try to push or pull from this new THg 1.1.8 machine, I get the
>>>>> following error:
>>>>> abort: error: _ssl.c:490: error:14090086:SSL
>>>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>>>> Yes. The windows installers started shipping with a cacerts file
>>>> configured. That could be considered a convenient security improvement
>>>> for some users, but it is a regression for those with self-signed
>>>> certificates.
>>> I'm far from being an expert in that area, but I do find this a very
>>> strange view.
>>>
>>> Given that Mercurial as installed by these installers now finally checks
>>> the certificates *at all* and *by default* -- which benefits the vast
>>> majority of the users -- is probably the lesser evil than simply
>>> throwing a warning at everyone downloading and installing this stuff.
>>
>> Perhaps. But it is a regression for those with self-signed certificates.
>
> I wouldn't call something that didn't work at all (or rather: only
> worked with a gaping security whole like that) a regression.

That is in my opinion not a correct description.

The role of web.cacerts was made (quite) clear when SSL server 
certificate verification was introduced one year ago (
http://selenic.com/repo/hg/rev/4c94a3df4b10 ). I made the role of 
web.cacerts more clear in 1.7.3 with the warning introduced in 
http://selenic.com/repo/hg/rev/2fa2e6444645 (where "will" should have 
been "would"). That is what caused all this fuzz.

The most serious issue here is that nobody noticed how they should use 
Mercurial with https connection. Few knew and nobody cared, so improved 
documentation wouldn't help. That is why I introduced a warning to make 
users aware there was something they should configure and some 
documentation they should read. I think it was so important that a new 
warning in stable was appropriate, but not so serious that more than 
that should be done in a bugfix release.

I think the next step should be to try to improve the situation with 1.8 
with better system integration, but I am not sure I would recommend 
packagers to do anything that would disrupt any use of Mercurial. It 
seems like I misjudged how users would react to the warning and how much 
fear and demand for action it would cause.


Then there was a bug in the cacerts check that made it almost worthless. 
That could be considered a gaping security hole. It was fixed in 
f2937d6492c5 before 1.7.


The whole Python/Mercurial SSL situation - and PKI in general - is a 
mess. There is no good solutions, so we have to consider the trade-offs.

When something worked as intended and documented in 1.7.2 and suddenly 
stops working in a minor update to 1.7.3 then it is a regression in my book.

It is possible that a regression can be justified if it is necessary to 
fix a security issue, but then we should do that deliberately and 
explain that to the users.


Adrian, it is fine that disagree with me, but I don't think it is OK 
that you just removed the half of my reasoning on the wiki that you 
don't like - 
http://mercurial.selenic.com/wiki/CACertificates?action=diff&rev1=14&rev2=15

Anyway, I can see that Matt just restored the balance by removing the 
part you agree with.

/Mads


More information about the Mercurial-devel mailing list