Re: Remove AUTH_REQ_KRB4 and AUTH_REQ_KRB5 in libpq code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove AUTH_REQ_KRB4 and AUTH_REQ_KRB5 in libpq code
Date: 2023-03-19 22:53:28
Message-ID: 806567.1679266408@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> $subject has been discussed here, still seems worth its own thread for
> clarity:
> https://www.postgresql.org/message-id/4037249.1679011812@sss.pgh.pa.us

> Support for Kerberos v4 has been removed in a159ad3 (2005) and the
> same happened for v5 in 98de86e (2014, meaning that this is still
> possible with 9.2 and 9.3 backends). Anyway, the attached seems worth
> the simplifications now? This includes a cleanup of protocol.sgml.

9.2 is still within our "supported old versions" window, so it's
at least plausible that somebody would hit this for KRB5. Still,
the net effect would be that they'd get "authentication method 2
not supported" instead of "Kerberos 5 authentication not supported".
I lean (weakly) to the idea that it's no longer worth the translation
maintenance effort to keep the special message.

A compromise could be to drop KRB4 but keep the KRB5 case for
awhile yet.

One other thought is that I don't really like these comments
implying that recycling these AUTH_REQ codes might be a good
thing to do:

+/* 1 is available. It was used for Kerberos V4, not supported any more */

I think we'd be better off treating them as permanently retired.
It's not like there's any shortage of code space to worry about.
More, there might be other implementations of our wire protocol
that still have support for these codes, so that re-using them
could cause compatibility issues. So maybe write "reserved"
instead of "available"?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-03-19 22:59:12 Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Previous Message Melanie Plageman 2023-03-19 22:50:16 Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode