Re: pg16 && GSSAPI && Heimdal/Macos

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(at)cryptonector(dot)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
> --
>