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 <n...@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 > -- >
