Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bruce(at)momjian(dot)us
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: "cert" + clientcert=verify-ca in pg_hba.conf?
Date: 2020-09-28 00:21:51
Message-ID: 20200928.092151.1414884371605871216.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

At Fri, 25 Sep 2020 13:30:06 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in
> On Thu, Sep 24, 2020 at 09:59:50PM -0400, Tom Lane wrote:
> > Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> > > Thank you Bruce, Michael. This is a rebased version.
> >
> > I really strongly object to all the encoded data in this patch.
> > One cannot read it, one cannot even easily figure out how long
> > it is until the tests break by virtue of the certificates expiring.

I thought the same but the current source tree contains generated
certificates, perhaps for developer's convenience. This patch follows
the policy (if it is correct..). If certificates expiring matters,
don't we need to remove the certificates in the current tree?

(Anyway we experenced replacement of existing certificates due to
obsoletion of a cipher algorithm and will face the same when the
current cipher algorithm gets obsolete.)

> > One can, however, be entirely certain that they *will* break at
> > some point. I don't like the idea of time bombs in our test suite.
> > That being the case, it'd likely be better to drop all the pre-made
> > certificates and have the test scripts create them on the fly.
> > That'd remove both the documentation problem (i.e., having readable
> > info as to how the certificates were made) and the expiration problem.
>
> I am not planning to apply the test parts of this patch. I think
> having the committer test it is sufficient.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-09-28 00:22:29 Planner making bad choice in alternative subplan decision
Previous Message Tom Lane 2020-09-27 23:58:55 Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros