[PATCH 2 of 6] sslutil: move sslkwargs logic into internal function (API)

Gregory Szorc gregory.szorc at gmail.com
Fri May 27 11:06:59 EDT 2016



> On May 27, 2016, at 07:52, Yuya Nishihara <yuya at tcha.org> wrote:
> 
>> On Wed, 25 May 2016 20:03:51 -0700, Gregory Szorc wrote:
>> +def wrapsocket(sock, keyfile, certfile, ui, serverhostname=None):
>>     """Add SSL/TLS to a socket.
>> 
>>     This is a glorified wrapper for ``ssl.wrap_socket()``. It makes sane
>>     choices based on what security options are available.
>> 
>>     In addition to the arguments supported by ``ssl.wrap_socket``, we allow
>>     the following additional arguments:
>> 
>>     * serverhostname - The expected hostname of the remote server. If the
>>       server (and client) support SNI, this tells the server which certificate
>>       to use.
>>     """
>>     if not serverhostname:
>>         raise error.Abort('serverhostname argument is required')
>> 
>> +    cert_reqs, ca_certs = _determinecertoptions(ui, serverhostname)
> 
> I'm writing tests of mail.py, and found this patch seems to change the
> behavior.
> 
> hg 3.8.2, with web.cacerts=unknown-ca.pem:
> 
>   a) --insecure:             warning + patch sent
>   b) smtp.verifycert=False:  no warning + patch sent
>   c) smtp.verifycert=loose:  CERTIFICATE_VERIFY_FAILED
>   d) smtp.verifycert=strict: CERTIFICATE_VERIFY_FAILED
> 
> hg 9da137faaa9c, with web.cacerts=unknown-ca.pem:
> 
>   a) --insecure:             warning + patch sent
>   b) smtp.verifycert=False:  CERTIFICATE_VERIFY_FAILED
>   c) smtp.verifycert=loose:  CERTIFICATE_VERIFY_FAILED
>   d) smtp.verifycert=strict: CERTIFICATE_VERIFY_FAILED
> 
> As of 3.8.2, verifycert=loose doesn't appear to agree with the doc if cacerts
> is specified or modern Python used. verifycert=False is broken at the current
> tip.
> 
> Do we still have to support smtp.verifycert in addition to --insecure option?
> SSL without verification is utterly insecure.

I was hoping to kill smtp.verifycert and replace with a newer, unified mechanism for host security. I was going to start those patches soon since the sslutil pre-work/refactor is mostly done.

I support a BC patch to drop smtp.verifycert. It will leave @ in a weird state until my stuff lands. But that should only last a week or two. You should be able to work around by defining cacerts or host fingerprints in the interim.


More information about the Mercurial-devel mailing list