On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian <bruce@momjian.us> wrote in
> bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > > At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in
> > > > > Because we think we need any named value for every alternatives
> > > > > including the default value?
> > > >
> > > > Well, not putting clientcert at all gives the default behavior, so why
> > > > have clientcert=no-verify?
> > >
> > > clientcert=verify-ca or verify-full don't allow absence of client
> > > certificate. We need an option to allow the absence.
> >
> > Isn't the option not specifying clientcert? Here are some valid
> > pg_hba.conf lines:
>
> Sorry for the ambiguity. Perhaps I understand that we talked at
> different objects. I was mentioning about the option value that is
> stored *internally*, concretely the values for the struct member
> port->hba->clientcert. You are talking about the descriptive option in
> pg_hba.conf.
>
> Does the following discussion make sense?
>
> We need to use the default value zero (=clientCertOff) for
> port->hba->clientcert to tell server to omit checking against CA if
> cert is not given. I suppose that the value clientCertOff is labeled
> as "no-verify" since someone who developed this thought that that
> choice needs to be explicitly describable in pg_hba.conf. And my
> discussion was following that decision.
>
> I understand that the label "no-verify" is not essential to specify
> the behavior, so I don't object to removing "no-verify" label itself
> if no one oppose to remove it.
>
> My point here is just "are we OK to remove it?"
Yes, in PG 14. Security is confusing enough, so having a mis-named
option that doesn't do anything more than just not specifying clientcert
is not useful and should be removed.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
