[PATCH] pg_hba.conf : new auth option : clientcert=verify-full

From: Marius Timmer <marius(dot)timmer(at)uni-muenster(dot)de>
To: Julian Markwort <julian(dot)markwort(at)uni-muenster(dot)de>, David Fetter <david(at)fetter(dot)org>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, arne(dot)scheffer(at)uni-muenster(dot)de
Subject: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full
Date: 2018-10-25 13:08:11
Message-ID: f14dd758-98c4-ff1f-4f87-28c076bd56e8@uni-muenster.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear hackers,

We (Julian and I) would like to show you the seventh version of this
patch which includes all the things mentioned before. Unfortunately
we did not find the time to do this earlier.

On 07/19/2018 03:00 AM, Thomas Munro wrote:
> you could just have one common code path to reach CheckCertAuth()
> for all auth methods after that switch statement, instead of the more
> complicated conditional coding you have now with two ways to reach it.
There is only one path now to call CheckCertAuth(). I don't think we
have left too many complicated conditions.

> That would result in a couple less LOC and a bit clearer conditionals,
> I agree.
> If there are no objections to make uaCert a quasi-alias of uaTrust
> with clientcert=verify-full, I'll go ahead and change the code
> accordingly.
uaCert and uaTrust are handled the same within the switch statement.

> I'll make sure that the error messages are still handled based on
> the auth method and not only depending on the clientcert flag.
As far as I know we already handled the error message based on the auth
method and clientcert flag.

On 07/30/2018 12:20, Julian Markwort wrote:
> I'm open for suggestions, but in absence of objections I might just
> capitalize all occurrences of CN.
We decided to stick with the old style for now. So we changed all
occurrences of cn to lower case.

> Yes, we should adopt the new style in all places.
> I'll rewrite that passage to indicate that cert authentication
> essentially results in the same behavior as clientcert=verify-full.
> The existing text is somewhat ambiguous anyway, in case somebody
> decides to skip over the restriction described in the second sentence.
We fixed that. Additionally we added the alias "no-verify" for
clientcert=0 since it seems to be a good idea to have aliases for all
three available values.

> > What do you think about using clientCertCA for the enumerator name
> > instead of clientCertOn? That would correspond better to the names
> > "verify-ca" and "verify-full".
> +1
> I'm not sure if Magnus had any other cases in mind when he named it
> clientCertOn?
We agree that clientCertCA is a better name for it. Since Magnus does
not seem to have any concerns about it we changed that as well.

Julian and I think the time has come for this patch to make some
progress. After a few months I think there is not that much to discuss
anymore.

Kind regards,

Marius Timmer

--
Westfälische Wilhelms-Universität Münster (WWU)
Zentrum für Informationsverarbeitung (ZIV)
Röntgenstraße 7-13
Besucheradresse: Einsteinstraße 60 - Raum 101
48149 Münster
+49 251 83 31158
marius(dot)timmer(at)uni-muenster(dot)de
https://www.uni-muenster.de/ZIV

Attachment Content-Type Size
clientcert_verify_full_v07.patch text/x-patch 15.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2018-10-25 13:25:31 Re: Question about xmloption and pg_restore
Previous Message Jehan-Guillaume de Rorthais 2018-10-25 13:03:51 Re: Using old master as new replica after clean switchover