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

[Sam Hartman]

Hi.  I have been thinking about this more and realize that there is
probably a better approach.

Your current approach is problematic because you link an
implementation of the CCAPI RPC into the application.  However CCAPI
is specified at the API layer not at the RPC layer.

Instead, what you want to do is link against the system CCAPI
implementation.  Preferably you'd just link against the Kerberos
framework.

But you can't do that if you are a Kerberos implementation because you
wi/will have symbol conflicts.

What if you provide a library (preferably static) that has all the
CCAPI entry points.  When one of these entry points is called, that
library should  then dynamically open the Kerberos framework and
dynamically generate a reference to the appropriate entry point in the
system Kerberos framework.




This assumes that OSX has a mechanism for opening a framework without
 influencing the running application's namespace.  I suspect this is
 true because without this feature it is almost impossible to
 implement plugins that work.

I suspect the Heimdal developers would be very interested in such a
library..  I also suspect that maintaining such a library would be a
lot less effort than maintaining a bunch of patches.

That said, we are still a bit concerned about the support implications
for us.  In an ideal world, everyone would use the system Kerberos
framework and would get support from Apple.  We'd work with Apple.
There would be no other versions of Kerberos than that provided by the
OS.

There are a lot of reasons we don't (and cannot) live in that world.
So MIT still releases Kerberos and people besides OS vendors use our
Kerberos release.

But we don't want to be put in a position of supporting or being
expected to support anything for OSX other than KFM.  ANd we only want
that support to come through Apple.

So, please consider the support issues when you consider what you do.
I suspect we'll be more concerned with results than with waht you
actually do.  But here are some cases  that would definitely make us
unhappy if they happened:

1) If we get bug reports, spend a lot of time debugging them, and find
   they are bugs in your software rather than our software.  This is
   especially true if the bug report is phrased in a way that we don't
   even know your software is involved.  For example we would be
   frustrated if we got a bug report about Kerberos ssh not working,
   assumed it was a version shipped by Apple, and later found that it
   was something built against an unreleased version of krb5 using
   your ccache glue library.


2) Even if its clear that bugs aren't our problem, we'd be annoyed if
   many users think that reporting problems in components we don't
   distribute to us is appropriate.

3)  If some third party application ends up using some non-documented
    or non-public API and this usage makes it difficult to to change
    that API.  


4) If decisions by third-party software vendors make it harder for
4) Third party software should not get in the way of  users upgrading
4) their OS or Kerberos.

5) Problems in third-party software should not reflect badly on MIT or
   Apple.  

However I certainly don't want to discourage you from discussing this
project on krbdev at mit.edu or asking us questions about implementation
details on krbdev.  I also don't want to discourage any potential
users from discussing or asking about the project on
kerberos at mit.edu/comp.protocols.kerberos.

--Sam