PAC Sucess!

[Jeremy Allison]

On Wed, Aug 31, 2005 at 05:30:11AM +1000, Andrew Bartlett wrote:
> 
> My position (which I know others disagree with) is that we should
> release Samba4 with the builtin Heimdal, and that once we know both how
> it really works in production (including issues we will show up in the
> kerberos code, and our interfaces to it), we can start on a real list of
> changes required to support other kerberos distributions.  
> 
> Then starts a massive task of implementing a set of configure checks for
> all our assumed behaviours, and the writing of a small glue layer (where
> the two development communities have, and cannot change, incompatible
> interfaces).  However, if the glue layer and #ifdef hell becomes like
> samba3's clikrb5.c (but an order of magnitude worse, because we use a
> lot more functions), then it will be a failure.  

Yeah I don't think we should do that. How about writing an abstraction
layer instead - and using our current heimdal wrappers as an implementation
of that.

Then if I ever get out of Samba3 RPC hell maybe I can just grab MIT
kerberos code right out of their 1.4.2 release and use it to create
a second implementation that has dependencies on MIT code, in much
the same way the current code depends on heimdal.

This seems to me to be the easiest way to get something MIT-compatible,
which as you know I think may be rather important :-).

> I do hope not to be maintaining a kerberos library and KDC for the rest
> of my days, but the timeframe I've discussed with the MIT developers is
> in the order of 2 years.  I figure it will take at least that long to
> both know what we need, and have that in major OS distributions.  

Yes, but once we have large chunks of the MIT code nailed into Samba4,
(in the same way that Heimdal is) this might piss them off enough to 
get them to fix things in a more reasonable timeframe.

I think creation of an abstraction interface above the current
heimdal specific code is probably key to this (all IMHO of course
as I'm not currently writing the code :-).

Jeremy.