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

Wehere did this end up getting decided?  I'm hoping, if it's going to
make it into main/master, it will be able to also make it's way ingo pg18.

As Nico wrote, my interest in opening this was especially for Apple's
implementation of Kerberos (and to a lesser extent NetBSD and FreeBSD)'s
which, today, happens to be based on Heimdal.  Additionally, the patch I
put out there, at Tom's suggestion, just makes build-time decisions and
isn't Heimdal specific, per say, just happens to land that way now.

Thanks,
-Todd

 > On Tue, Apr 08, 2025 at 02:18:40AM -0400, Tom Lane wrote:
 > > Nico Williams <nico@cryptonector.com> writes:
 > > > Heimdal in the master branch sure does; I'm the author if
 > > > gss_store_cred_into() and gss_store_cred_into2().  Idk when we'll do an
 > > > 8.0 release though.  We've run out of steam.
 > >
 > > Yeah, this is what makes me fearful about putting in changes to re-support
 > > Heimdal.  It seems like it's more or less abandonware so far as the
 > > upstream developers are concerned, which is not comforting with any
 > > package, but especially not for security-critical code.  I understand
 >
 > Right now heimdal/heimdal basically is abandonware, yes, but not
 > Apple's.  I wish it weren't so as I've had a great deal of fun working
 > on it over the past decade plus, but there's loads of other things to
 > work on.
 >
 > > that downstream packagers such as Apple and the BSDen are trying to
 > > fill the gap, but how much should their efforts be relied on?
 > >
 > > We could certainly take the attitude suggested upthread that
 > > "we'll allow you to build with Heimdal, and if it breaks you
 > > get to keep both pieces".  But I dunno.  We get blamed when
 > > users do obviously-stupid stuff like use a guessable superuser
 > > password on a database they've exposed to the internet [eg, 1].
 >
 > It's the _GSS-API_.  It's pretty much a standard.  You're making use of
 > a non-standard extension (gss_store_cred_into()) that's not strictly
 > needed since you could just either a) keep the gss_cred_id_t value
 > output by gss_accept_sec_context() and use that if needed anywhere
 > (probably only postgres_fdw), or b) not accept delegated credentials.
 > (a) might require changes to the interface to extensions, idk.  But
 > anyways, if you were not using non-standard extensions then you wouldn't
 > need to care if the user wants to link postgres with Heimdal or MIT or
 > anything else.  Heck, there's a GSS wrapper around SSPI that can be used
 > on Windows even (though it's obscure).
 >
 > gss_store_cred() is a standards-track RFC, though it turns out to not be
 > good enough, which is why gss_store_cred_into() and
 > gss_store_cred_into2() exist, but in this particular case (PG)
 > gss_store_cred() is in fact good enough (see other reply).
 >
 > > It would be a lot more obviously our fault if we say nothing
 > > when a user chooses a known-insecure library to build against.
 >
 > Sure.
 >
 > > So I've still got really mixed emotions about this project.
 > > I totally understand the desire to use these library versions,
 > > but I can't help fearing that people will regret doing so ...
 > > and then want to shift the blame to us.
 >
 > In this case OP wants to use _Apple_'s Heimdal so they can make sure
 > they're using Apple's API: ccache.  Apple presumably supports their
 > Heimdal fork even if the upstream is currently abandonware-ish.  I think
 > you should always allow the use of the OS's authn. infrastructure where
 > you have the code for it.
 >
 > Nico
 > --
 >