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