Re: pg16 && GSSAPI && Heimdal/Macos

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Todd M(dot) Kover" <kovert(at)omniscient(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg16 && GSSAPI && Heimdal/Macos
Date: 2025-03-08 19:02:59
Message-ID: 24600.1741460579@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Todd M. Kover" <kovert(at)omniscient(dot)com> writes:
> To that end, I'd like to propose a --with-gssapi-client-only type option
> that's mutually exclusive with --with-gssapi that will trigger gssapi
> linkage in just libpq but not in the backend. --with-gssapi would just
> turn on the same flag that --with-gssapi-client-only uses.

I don't see how that's a good idea. Notably, a system built that
way could not test its own GSS support.

Looking at the code a bit closer, I see that we will never try to
call gss_store_cred_into() unless the gss_accept_delegation GUC
is on --- which it is not by default. So that certainly blows a
large hole in the idea that this is something we have to have.
I think that a more-probably-acceptable patch would be to set up
the code so that we can build without gss_store_cred_into() and
what the user sees is gss_accept_delegation can't be turned on.

I remain doubtful that this is a good idea from a big-picture
standpoint, though. What this amounts to is un-desupporting
the Heimdal Kerberos libraries, which is a big deal from a
testing standpoint if nothing else. Plus we'd be encouraging
people to depend on security-critical software that is, if
not effectively dead, at best in back-burner maintenance mode.

Is there a good reason why you can't build your Mac PG code
with MIT Kerberos from Homebrew or MacPorts?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2025-03-08 19:09:51 Re: Statistics Import and Export
Previous Message Todd M. Kover 2025-03-08 17:38:08 Re: pg16 && GSSAPI && Heimdal/Macos