Using KfM's credentials cache with Krb5 1.3 on OS X 10.2.6

[Steven Michaud]

I intend libCredCache (and my CCAPI patch to 1.3) to be a stop-gap for
use only until a version of KfM appears that is based on 1.3 (or
1.3.1).  Is that targeted for Panther?  (By the way, I haven't yet
seen Panther and don't know what Kerberos code it contains.)

If a KfM based on 1.3.X takes more than a few months to appear, or if
there's a lot of interest, I'd consider doing a binary distribution of
the shared library (libCredCache.dylib) (together with instructions on
how to build it yourself).  As far as I can tell it doesn't contain
any encryption code, so I wouldn't have to worry about export
restrictions.  (I wouldn't want to try distributing the static
libraries -- there are too many of them, and they have too many
external dependencies.)

What do you think would be the "right places" for this?  Would MIT be
interested?

In the meantime I'd like to leave things as they are:  People can build
their own copies of libCredCache (if they can, they presumably know
what they're doing), and start playing around with it.  Any problems
they may have with it will come out in the wash.

It _would_ be nice to see the CCAPI more widely supported.  What are
the "other things" that might need to change first?

On Tue, 22 Jul 2003, Sam Hartman wrote:

> One quick thought.  Distributing a new shared library is probably a
> bad idea unless you are willing to commit to the ABI and name of that
> library and arrange to make sure it is available in the right places.
>
> Distributing a static library is also problematic.  I don't know to
> what extent we guarantee that the client sides of the RPCs to the
> cache server will be stable between versions of KFM.  I believe we do
> make this guarantee for KFW, but suspect we are actually fairly
> willing to change these interfaces without notice on the KFM side.
>
>
> I think long-term we'd like to be able to build krb5 to use CCAPI
> everywhere, but we would not be interested in supporting patches to do
> so right now.  There may need to be some other things that change
> first.
>
> Also, since you specifically mentioned new encryption types, please
> note that there is a significant problem with krb5 1.3 and we plan to
> be releasing a beta of 1.3.1 shortly.
>
>
>