Horton

Re: Problem with ssl and psql in Postgresql 13

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Gustavsson Mikael <mikael.gustavsson@smhi.se>, Magnus Hagander <magnus@hagander.net>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>, Svensson Peter <peter.svensson@smhi.se>
Date: 2020-12-30T16:41:14Z
Lists: pgsql-general 
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> I think we'd be best off to always override KRB5_KTNAME if we have a
>> nonempty krb_server_keyfile setting, so the attached proposed patch
>> makes both functions do it the same way.  (I did not make an effort
>> to remove the dependency on setenv, given the nearby thread to
>> standardize on that.)

> +1.

Done, thanks for looking at the patch.

>> I'm not sure whether there's any documentation change that needs to
>> be made.  The docs don't suggest that you're allowed to set
>> krb_server_keyfile to an empty string in the first place, so maybe
>> we needn't explain what happens if you do.

> Perhaps saying something about 'system default' or 'taken from the
> environment' might make sense.

I went with "If this parameter is set to an empty string, it is ignored
and a system-dependent default is used."  I don't think we need to go
into more detail than that, since as you say it's unlikely to be a
useful case.

			regards, tom lane

Commits

  1. Fix up usage of krb_server_keyfile GUC parameter.

  2. Improve log messages related to pg_hba.conf not matching a connection.

  3. Fix assorted issues in backend's GSSAPI encryption support.

  4. Fix bugs in libpq's GSSAPI encryption support.