[PATCH 4 of 9 V2] sslutil: restore behavior of web.cacerts=! to disable CA loading

[Gregory Szorc]

On Wed, Jun 1, 2016 at 5:44 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 06/01/2016 03:20 PM, Yuya Nishihara wrote:
> > On Tue, 31 May 2016 19:22:00 -0700, Gregory Szorc wrote:
> >> # HG changeset patch
> >> # User Gregory Szorc <gregory.szorc at gmail.com>
> >> # Date 1464639083 25200
> >> #      Mon May 30 13:11:23 2016 -0700
> >> # Node ID 317bb3df2da17ffd258ca80072a6fbb0e36b84a1
> >> # Parent  1b9bbb794da9681fd6639f321a0156c75ece764f
> >> sslutil: restore behavior of web.cacerts=! to disable CA loading
> >>
> >> This commit logically reverts ef316c653b7f.
> >>
> >> There are various tests for behavior when CA certs aren't loaded.
> > n> Previously, we would pass --insecure to disable loading of CA
> >> certs. This has worked up to this point because the error message
> >> for --insecure and no CAs loaded is the same. Upcoming commits will
> >> change the error message for --insecure and will change behavior
> >> when CAs aren't loaded.
> >>
> >> This commit restores the ability to disable loading of CA certs
> >> by setting web.cacerts to "!". Unlike the previous implementation
> >> which treated web.cacerts=! and --insecure as equivalent, this version
> >> explicitly disables loading of CA certs when web.cacerts=!, even if
> >> system/default CA certs are available.
> >
> > If this is only for testing, I would add new option under debug. or
> devel.
> > section.
>
> +1, if this is intended for testing only, something in devel would fit.
>
> If there is valid usecase in the wild, this seems fine (even if a bit
> arcane, at least it is the same arcane than before), some explicite
> option might still be better if we introduce a new behavior (for this
> hypothetic valid usecase)
>

Specifying a fingerprint makes CAs irrelevant. Specifying --insecure
disables all security, including CA loading and certificate verification.
And I have plans to facilitate specifying per-host CAs, which would
override web.cacerts. So I don't think web.cacerts=! has any value in the
wild.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160601/5d8c9947/attachment.html>