Re: patch: Client certificate requirements - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: patch: Client certificate requirements
Date
Msg-id 34d269d40811151834g2fdb785at3a62022d5007fa11@mail.gmail.com
Whole thread Raw
In response to Re: patch: Client certificate requirements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: patch: Client certificate requirements  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Sat, Nov 15, 2008 at 17:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Alex Hunsaker" <badalex@gmail.com> writes:
>> Err that really should be ereport(FATAL,
>
> I don't think that's a particularly user-friendly design.
>
> The behavior I'd expect to see is
>
> 1. Root cert file not there: issue existing LOG message.  Maybe the user is
> expecting client cert verification, and maybe he isn't, but it is a good
> idea to put out the LOG message just to make sure he knows what will
> happen.

Right, pre patch I agree with you.  The problem I noticed with the
patch is we say nothing if its there and you can't read it.  The whole
point of the patch is to give you the option of forcing client certs.
So why LOG every server start up just because I turned on ssl.  If
pg_hba is setup right you'll get the appropriate error message when
the client connects.

Maybe NOTICE is more appropriate?

I don't really care either way though.  Ill let you and Mangus duke it out :

> 2. Root cert file present but we fail to load it: FATAL is probably okay
> here, but not with that hint message.

Err, I was just trying to be congruent with HEAD.  Currently that's
the message you get if we could not "read" the root cert.  (as a LOG,
not FATAL). Should just drop the hint and keep the FATAL for this
case?

Also we check that the private key is at least 0600, should we be
doing the same for the root cert?


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: patch: Client certificate requirements
Next
From: Andrew Chernow
Date:
Subject: Re: Compiling on HP-UX 10.20 fails