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
--
