[PATCH] ui: optionally quiesce ssl verification warnings

[Steven Stallion]

On Mon, Apr 9, 2012 at 5:06 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> Steven Stallion wrote, On 04/09/2012 12:30 AM:
>
>> # HG changeset patch
>> # User Steven Stallion<sstallion at gmail.com>
>> # Date 1333924158 25200
>> # Node ID 87d271ff44bd1f06b3eeee36439f3c0306793516
>> # Parent  329887a7074c8e49e73fa76712d8d45aee0d0fd7
>> ui: optionally quiesce ssl verification warnings
>>
>> Some platforms, notably Plan 9 from Bell Labs are stuck on older
>> releases of Python. Due to restrictions in the platform, it is not
>> possible to backport the SSL library to the existing Python port.
>
> Does that mean that Plan 9 is dead and it never will be able to run a recent
> Python?

I think it means that some platforms are a tad tougher to port than
others. Plan 9 has a few restrictions which affect SSL in a very big
way, mainly that Python assumes OpenSSL semantics and that dynamically
loaded libraries are not supported. This essentially means that Python
must be recompiled for any extension change. Porting to a new version
of Python is non-trivial and it is out of scope for the work I am
pursuing at the moment. In a perfect world yes, there would be many
more users interested in advancing the state of Python on the platform
and we wouldn't have this conversation.

> Or just that it currently ships with Python 2.5 and you can't/won't update
> Python or install the standalone ssl module?

See above.

>> This patch permits the UI to quiesce SSL verification warnings by
>> adding a configuration entry named report_unverified to ui.
>
> A SSL connection that haven't been verified is no more secure than a non-SSL
> connection. Any support to the idea of having 'SSL with unverified
> certificate' is misguided and will be seriously misleading. (If it wasn't
> for the need for backward compatibility then I would have recommended that
> Mercurial should abort instead of warn in this and other insecure cases.)

This is a half-truth. Loss of verification does not impact encryption,
merely verification of MITM or similar attacks. That said, I am not
happy with the need for this patch whatsoever. Spamming users multiple
times while still permitting the operation is very annoying. Admitting
that running on Python 2.5 is less than desirable is one thing, making
the user experience miserable is another.

> I don't think this new configuration option just to hide a real issue
> without fixing it is a good idea. It would perhaps be a slightly less bad
> idea if the option name and the documentation made it clear that it was
> insecure.

I've been fortunate enough for my employer to allow me to do this on
their dime so far. I won't be able to sell doing a new Python port as
well. I agree that getting the platform up to at least 2.7 would be
ideal, but this work can't come from me. I'm a kernel hacker by trade
- I lack the Python chops to do a proper port myself.

> If you really want to feel safe while being insecure then I would recommend
> making a little extension that replace mercurial.sslutil.validator with
> something like lambda *a: lambda *a: None . Or even better: Do whatever it
> takes to bring SSL to your Python.

The goal is to submit something that useful to a wider audience and to
get away from site-specific hacks. I wanted to make this lexically
similar to report_untrusted. If you rely on on-filesystem
repositories, report_untrusted is an important message with regard to
security, yet we allow users to quiesce the warning. Why? Well, users
will always know more about their environment than the software.
report_unverified is no different. Yes, it's a bad idea, but in
certain environments, it's use is critical - especially when used on a
trusted network.

FWIW, this is only used on Python 2.5 hosts where we cannot backport
the ssl 1.5 library. All other hosts are configured for the proper
hostfingerprint for the certificate.

Cheers,

Steve