Aidan Cully <aidan@kublai.com> writes:

> I'm assuming kerberos5 is something we want in the tree.  If it isn't,
> then it isn't.
> 
> This is less a completely hashed out proposal than a list of steps that I'm
> planning to take to get krb5 integrated..  The descriptions of the steps
> should give a pretty good indication of what the finished product should
> look like, though..  If you've got questions about this, please ask.
> 
> I believe I can have krb5 in the tree, and working decently by 7/14.
> 
> --aidan

It is, but given that most of the world will feel that they are unable to
use it, I wonder what the point is.

kth's very full featured exportable krb4 replacement is available from:

<http://www.pdc.kth.se/kth-krb>

This is code was integrated into the OpenBSD tree a while back, and
would be incredibly easy to take from there. Before they fled in
terror, there were a few SNI kerberos hackers working on the OpenBSD
tree who were reasonably clued up (about kerberos). The OpenBSD
integration and patches are probably of some non-negative value, and
unless they severly botched the CVS vendor branching it would be
bloody mindedness on our part not to take advantage of them.

hiemdal, kth's exportable krb5 replacement seems to be at the point of
usefulness, and judging by the distribution dates is still receiving
significant developer attention. The last time I looked, mit krb5 was
languishing and bug-ridden (which of course doesn't mean it isn't
functional, but you expect better from crypto-software).

<http://www.pdc.kth.se/heimdal/>

Julian.