[PATCH 3 of 3] [RFC] sslutil: try to find and use system CA file when appropriate

Gregory Szorc gregory.szorc at gmail.com
Fri Jul 1 10:41:17 EDT 2016



> On Jul 1, 2016, at 07:02, Yuya Nishihara <yuya at tcha.org> wrote:
> 
>> On Thu, 30 Jun 2016 08:06:25 -0700, Gregory Szorc wrote:
>> ssl.SSLContext.load_verify_locations() specifies 2 ways to load certs: via
>> a single file and via a path containing files with hashes of CAs.
>> 
>> When you load a directory, the certs are loaded on demand as they are
>> encountered through connection activity. Only then do the certs show up in
>> cert_store_stats().
>> 
>> Debian and Ubuntu appear to be using this directory-based cert loading.
>> RHEL is using the file-based one. And FWIW Mercurial only supports
>> specifying a config option for loading certs from a file. We /could/
>> support loading from a directory if we wanted. Although I haven't heard
>> anybody clamor for this, so I'm not going to do it.
> 
> Ah, that's why I saw nothing returned by get_ca_certs() until a socket
> connected to somewhere.
> 
> On Windows, CA certificates seem to be loaded by create_default_context(),
> but it might be an implementation detail.
> 
>> Anyway, what this means is that "are any CAs loaded" is a bit difficult to
>> implement on systems loading certs from directories because CA count == 0
>> could mean either no CAs loaded or the CA wanted by the server connection
>> just isn't present locally. I'll likely have to tweak the warning message
>> for "no CAs loaded" that I added a few hours ago and Yuya recently queued.
>> I'll also have to look into behavior on Windows and OS X to see if they are
>> reporting counts in cert_store_stats(). Perhaps it would be best to prune
>> that last patch from the committed repo until I get a handle on things. If
>> not, I'll send follow-up commits.
> 
> The patch has been published due to the lag of the list?

Don't worry about it. I have a series in the works to overhaul default CA loading. I'll address wording changes there, if necessary.


More information about the Mercurial-devel mailing list