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