Re: Remove AUTH_REQ_KRB4 and AUTH_REQ_KRB5 in libpq code

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 23:48:50
Message-ID: ZBefYoKDXcTHTtAF@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 19, 2023 at 06:53:28PM -0400, Tom Lane wrote:
> 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.

Hmm. I think that I would still drop both of them at the end, even in
v16 but I won't fight hard on that, either. The only difference is
the verbosity of the error string generated, and there is still a
trace of what the code numbers were in pqcomm.h.

> 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"?

Okay, fine by me.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-03-20 00:05:29 Re: Commitfest 2023-03 starting tomorrow!
Previous Message Michael Paquier 2023-03-19 23:43:27 Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry