[20264] in Kerberos_V5_Development
Re: Big Sur & MIT Kerberos no longer interoperate
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Sat Mar 20 09:40:25 2021
Message-ID: <202103201337.12KDbUR4021716@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <43d52b48-9445-72bd-a915-2716d6b730bf@mit.edu>
MIME-Version: 1.0
Date: Sat, 20 Mar 2021 09:39:53 -0400
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>It looks like it would require a fair amount of code for us to
>interoperate with the XCC cache, and unlike the KCM code, it wouldn't
>give us ancillary benefits on other platforms. So I'm not certain what
>we'll do. One option is to create a public ccache pluggable interface
>to allow maintenance of an XCC plugin module outside of our tree, but
>that (1) assumes someone would put in that work, and (2) would be harder
>to deploy than just building MIT krb5 and having it use the native
>ccache automatically.
One relatively simple possibility is to create a shim layer that
dlopen()'s the Heimdal framework and calls the appropriate credential
cache functions.
I kind of have to solve this problem sooner rather than later, and I
don't mind doing the work and contributing it to MIT. Like everyone
else we have been telling everyone not to upgrade to Big Sur, but I
know eventually systems are going to start shipping with Big Sur (and
of course Apple Silicon systems already are). If we could work out an
acceptable approach I can get to work on that and see where it leads me.
Maintaining an out-of-tree plugin ... well, we do that for some things,
but I can tell you from experience that it sucks. It's not so bad on
server systems that you manage, but it is a huge pain on client systems
that are administrated by users.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
