Mercurial vulnerability? CVE-2010-4237

Mads Kiilerich mads at
Thu Dec 9 11:14:30 CST 2010

On 12/09/2010 04:32 PM, Antoine Pitrou wrote:
> Mads Kiilerich<mads<at>>  writes:
>> 2. encourage packagers to configure cacerts by default - for Fedora that
>> could be by creating a /etc/mercurial/hgrc.d/cacerts.rc with
>> '[web]\ncacerts=/etc/pki/tls/certs/ca-bundle.crt'.
> How would this work under Windows? I'm not aware that this OS has certificates
> in the appropriate format.
> If you have a simple solution, Python would be interested :)

This is PKI, so nothing is simple and nothing is good. There is no 
solutions, only ways to make wrong assumptions and make it somebody 
elses problem. ;-(

Which CAs to trust is a policy decision. Mercurial (and Python) _could_ 
distribute a CA list in a format suitable for Pythons OpenSSL, but I 
don't think we should be the ones to suggest that the user should trust 
for example both the US, Chinese and Israel governments.

The operating systems have already made a decision about who to trust, 
so utilizing that seems like the "best" solution. There is no good 
generic "API" for that, so pushing the responsibility for this deep 
integration to the platform packagers seems like a good "solution".

Windows probably don't have a suitable CA certificate file, but it might 
be possible to do it with only 15-20 calls to crypt32.dll. doesn't expose all 
of , but there is 
always ctypes ;-)

On Fedora it would be preferable if the certificate could be checked 
through NSS and its certificate database.

I think Python (from this point of view) made an unfortunate decision by 
using OpenSSL and expose it in so many ways that it is almost impossible 
to use anything else without breaking API compatibility. Because of that 
there is no good solution. It could be argued that Python made the 
decision to use OpenSSL on all platforms, so Python should also take 
responsibility for managing the CAs. Somehow.

FWIW I think it would be "better" if python could utilize the different 
crypto libraries on the different platforms - for example OpenSSL, NSS, 
GnuTLS and some Windows crypto API. Exposing all these different APIs 
through a common, nice, efficient and sufficiently complete Python API 
is however probably almost impossible.


More information about the Mercurial-devel mailing list