Re: pg16 && GSSAPI && Heimdal/Macos

I spent some quality time with this and wanted to revisit. It still
applies for pg17 and master of git (I was mucking about with master in
git).

> > As you may have surmised, I use a mac as a client and use gssapi pretty
> > heavily to interact with numerous postgresql databases. This has stopped
> > me from upgrading my client side to 16. I'm wondering if there's be any
> > willingness to reconsider Heimdal support under some circumstances?
>
> The immediate reason for dropping that support is that Heimdal doesn't
> have gss_store_cred_into(), without which we can't support delegated
> credentials. AFAICT, Apple's version doesn't have that either.
> We could argue about how important that feature is and whether it'd be
> okay to have an Apple-only build option to not have it. However...
>
> ... there's another good reason to shy away from relying on Apple's
> library, which is that they've conspicuously marked all the standard
> Kerberos functions as deprecated. It's not clear if that means
> they're planning to remove them outright, but surely it's an indicator
> that Apple doesn't want outside code calling them.
>
> The deprecation notices that you get if you try to build anyway say
> "use GSS.framework". So if somebody wanted to try to support this in
> a somewhat future-proof way, the thing to do would be to look into how
> invasive it'd be to do it like that. That's not something I plan to
> put any effort into, but if you're desperate enough for this, maybe
> you could push that forward.

I looked into this more, and the libpq frontend parts build and work just
fine with Heimdal (at least on mac), but the _server side_ requires a
more modern Kerberos to make gss_store_cred_into work. I was basically
able to change setup a with_gssapi_client and ENABLS_GSS_CLIENT defines
in libpq and get it to build (I hacked it by hand to prove it out).
gss_store_cred_into is only called in the backend.

A pragma in code to ignore the apple deprecation notices and build
anyway. They use GSSAPI extensively internally, so there's not a lot of
danger of that going away but on the chance that Apple go through with
actually removing the standard interface, it's a matter of using similar
calls in the framework. (or someone may build a shim).

I have the same general issue with OS's such as FreeBSD where I _really_
don't want to build a whole second Kerberos library just to make the
client work. Server side, that's fine.

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.

In the future, if it stops building on the mac, then I'd probably end up
figuring out how to deal with migrating to the framework and kick back a
patch that would work with --with-gssapi-client-only.

My question is that if I submit a patch that does this, is there a
reasonable chance it would be accepted into the main branch. If not,
I'll just maintain something (probably less hardened) patch privately --
it's not a difficult thing to do cleanly, but I'd rather not. Obviously
you can't guarantee this until you see it, but I don't to bother if
there's no appetite. I'd test it on what I have available (macos,
FreeBSD, NetBSD, ubuntu).

thanks,
-Todd