From: | Nico Williams <nico(at)cryptonector(dot)com> |
---|---|
To: | kovert(at)omniscient(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg16 && GSSAPI && Heimdal/Macos |
Date: | 2025-04-08 05:46:48 |
Message-ID: | Z/S4SP4LccxOpAMo@ubby |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 06, 2023 at 06:54:22PM -0500, kovert(at)omniscient(dot)com wrote:
> I wanted to follow up on the decision to blow off Apple's built-in
> GSSAPI. Years back, for reasons I never found, Apple switched from MIT
> to Heimdal and have been maintaining their own version of it. I'm not
> clear how well they maintain it but they have enhanced it.
Apple switched because Apple hired then developers of Heimdal, and they
liked it better than MIT Kerberos. I have worked on both and know them
intimately well and I too prefer Heimdal, mainly because it has a very
nice ASN.1 compiler.
Apple does enhance their fork of Heimdal, and they publish their changes
with Darwin drops. But they do not contribute back to Heimdal.
> One of the things that Apple put it in was a different centralized
> credentials cache system. (named of the form "API:uuid"). This isn't
> in Heimdal nor is it in MIT, so typical kerberos tickets issued by the
Well, MIT and Heimdal support the KCM: cache type, which is an IPC
interface to the system credentials cache daemon, which is basically
what the API: cache type is, and they both support the CCAPI anyways,
which is also what the API: cache really is (basically it's a shared
object exporting an API for credentials caches). So they can both use
the OS X API: cache. Well, I think so -- I don't use OS X so I don't
know how well the OS X API: cache works with Heimdal or MIT Kerberos,
but I believe it should.
Nico
--
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-04-08 05:59:53 | Re: BUG #18815: Logical replication worker Segmentation fault |
Previous Message | Ashutosh Bapat | 2025-04-08 05:41:11 | Re: [PoC] Reducing planning time when tables have many partitions |