Re: Direct SSL connection and ALPN loose ends

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Direct SSL connection and ALPN loose ends
Дата
Msg-id CAOYmi+khV8Bg4EhnRt=EoMkktOsDtbzRRCjUfRoDzzK4LkV4ZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Direct SSL connection and ALPN loose ends  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Direct SSL connection and ALPN loose ends
Re: Direct SSL connection and ALPN loose ends
Список pgsql-hackers
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > By "negotiation" I mean the server's response to the startup packet.
> > I.e. "supported"/"not supported"/"error".
>
> Ok, I'm still a little confused, probably a terminology issue. The
> server doesn't respond with "supported" or "not supported" to the
> startup packet, that happens earlier. I think you mean the SSLRequst /
> GSSRequest packet, which is sent *before* the startup packet?

Yes, sorry. (I'm used to referring to those as startup packets too, ha.)

> Hmm, right, GSS encryption was introduced in v12, and older versions
> respond with an error to a GSSRequest.
>
> We probably could make the same assumption for GSS as we did for TLS in
> a49fbaaf, i.e. that an error means that something's wrong with the
> server, rather than that it's just very old and doesn't support GSS. But
> the case for that is a lot weaker case than with TLS. There are still
> pre-v12 servers out there in the wild.

Right. Since we default to gssencmode=prefer, if you have Kerberos
creds in your environment, I think this could potentially break
existing software that connects to v11 servers once you upgrade libpq.

Thanks,
--Jacob



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Следующее
От: Melanie Plageman
Дата:
Сообщение: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin