[PATCH 1 of 9 V2] mail: unsupport smtp.verifycert (BC)

[FUJIWARA Katsunori]

At Wed, 1 Jun 2016 22:51:16 +0900,
Yuya Nishihara wrote:
> 
> On Tue, 31 May 2016 19:21:57 -0700, Gregory Szorc wrote:
> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1464747586 25200
> > #      Tue May 31 19:19:46 2016 -0700
> > # Node ID a17ef4b3ffc9394a49edf4b509fbac04d223b324
> > # Parent  48b38b16a8f83ea98ebdf0b370f59fd90dc17935
> > mail: unsupport smtp.verifycert (BC)
> > 
> > smtp.verifycert was accidentally broken by cca59ef27e60. The current
> > code refuses to talk to a remote server unless the CA is trusted or
> > the fingerprint is validated. In other words, we lost the ability
> > for smtp.verifycert to lower/disable security.
> > 
> > There are special considerations for smtp.verifycert in
> > sslutil.validatesocket() (the "strict" argument). This violates
> > the direction sslutil  is evolving towards, which has all security
> > options determined at wrapsocket() time and a unified code path and
> > configs for determining security options.
> > 
> > Since smtp.verifycert is broken and since we'll soon have new
> > security defaults and new mechanisms for controlling host security,
> > formally deprecate smtp.verifycert. With this patch, the socket
> > security code in mail.py now effectively mirrors code in url.py and
> > other places we're doing socket security.
> 
> (+CC foozy as he should know the detail of smtp.verifycert)
> 
> I second this change, but "broken by cca59ef27e60" shouldn't be a reason.
> It isn't even released.
> 
> > -``verifycert``
> > -    Optional. Verification for the certificate of mail server, when
> > -    ``tls`` is starttls or smtps. "strict", "loose" or False. For
> > -    "strict" or "loose", the certificate is verified as same as the
> > -    verification for HTTPS connections (see ``[hostfingerprints]`` and
> > -    ``[web] cacerts`` also). For "strict", sending email is also
> > -    aborted, if there is no configuration for mail server in
> > -    ``[hostfingerprints]`` and ``[web] cacerts``.  --insecure for
> > -    :hg:`email` overwrites this as "loose". (default: strict)
> 
> IIRC, this option was introduced to mitigate the risk of breaking change
> in stable release, where user has web.cacerts but his SMTP server might
> provide a self-signed certificate, for example. For this purpose, "loose"
> seems useless. Also, "loose" appears not working from the beginning if
> cacerts are available.

FYI

As Yuya said, smtp.verifycert was introduced for backward
compatibility of existing tool chains.

"loose" for smtp.verifycert is corresponded to security level of
changeset exchanging via HTTPS in ordinary usecase.

  - if cacerts is available, validate server certificate strictly
    before starting communication

  - otherwise, start communication without validation, but show
    warning about it


> Now we're going to add a config knob to control per-host security features,
> and we'll provide a hint for it, I think dropping smtp.verifycert is
> acceptable.

I agree, too, Default value of smtp.verifycert has been "strict" since
Mercurial 2.6 released at 2013-05-01. This seems long enough.


> The series looks good to me except for a few nits.
> 

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp