Remove AUTH_REQ_KRB4 and AUTH_REQ_KRB5 in libpq code
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t47621psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:52 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t47621_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t47621_1 && git checkout t47621_1Patchset v1 (message #1) is on t47621_1
Hi all,
$subject has been discussed here, still seems worth its own thread for
clarity:
/messages/by-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.
Thoughts?
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
$subject has been discussed here, still seems worth its own thread for
clarity:
/messages/by-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
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