Opposite of --insecure is what?

[Mads Kiilerich]

On 02/04/2011 10:09 AM, Jason Harris wrote:
> Ok in making MacHg work with certificates for https:// and fingerprints and
> stuff the following issue has come up... Ironically I now have almost the
> opposite question to the ones I previously asked. How do I make the operation
> always fail if there is no verifiable certificate or fingerprint?

For now the way to do that is to specify a web.cacerts file. It can't be 
empty, but you can generate a random self-signed certificate and throw 
away the key.

It would make sense if Mercurial by default aborted instead of issuing a 
warning (unless --insecure was specified). Such a change would in my 
opinion have been too invasive for a stable bugfix release - that is one 
of the reasons we just give a warning (or a number of them ...).

The packaging guideline has however already been changed to recommend 
shipping Mercurial with web.cacerts configured and the windows 
installers already does that. That effectively changed the default.

Developers: Should we change the insecure warning to an abort in 1.8? 
With fallback to insecure+warning if web.cacerts=! ?

> But if I set up web.cacerts then things fail outright when connecting to a
> server with a self-signed certificate, but no fingerprint info is printed. Eg
>
> [Bolt:/Development/MacHgDev/MacHgDH] MacHgDH 2211(2211) ⌘ hg pull https://***@jasonfharris.com/hg/MacHg
> abort: error: _ssl.c:480: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
> (Note this is a scary error and really what has happened is that the self-signed
> certificate was unknown to Mercurial. It wasn't that it was trying to spoof
> something... The message shouldn't cry wolf. Maybe the message should be a
> little lighter for this case? (I gather from the code that this is coming
> through from a layer below Mercurial...)

Yes, that message is all we get from Python. AFAIK there is no way we 
reliably can give better error messages, and there is no way we can 
retrieve a fingerprint from the failing https session.

Mercurial _could_ create another connection just to retrieve the 
fingerprint. Creating extra network connections in a fatal exception 
handler is however not necessarily a good ide. Instead you can do it by 
connecting again, either insecurely or with an invalid fingerprint - or 
use a python one-liner.

> Why do I need a --authentication strict option?
...

Some brief comments:

"authentication" usually refers to the user authenticating to the 
server, and Mercurial already has an "auth" section for that. This 
should be called something else - I don't know what. Perhaps something 
like "serveridentity".

We would certainly like to see much of what you are asking for.

Mercurial is however constrained by what Python ssl allows.

Another constraint is backward compatibility. Some of our users start 
complaining whenever anything changes.

Mercurial would certainly look differently in this area if we could 
redesign it from scratch without these constraints.

TortoiseHg 1.9 has the same challenges as you have, and Steve has been 
through the same thoughts a month ago and worked closely with the other 
Mercurial developers to create an optimal solution. Check it out and get 
inspiration there.

/Mads