Re: pg16 && GSSAPI && Heimdal/Macos - Mailing list pgsql-hackers

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