"Todd M. Kover" <kov...@omniscient.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
