Re: documentation vs specification

On Mon, 2011-10-03 at 13:19 -0400, [email protected] wrote:
> My problems _are_ being solved using ccaches. I am in fact reasonably
> happy with the result. I am unhappy with the state of the affairs when
> my happiness (and happiness of my users) depends on teams of developers
> (Heimdal and Shishi) having to reverse engineer and track what a third
> team (MIT) chooses, apparently without any cooperation with the others'
> efforts.

The MIT krb5 team is quite aware that Heimdal and Shishi share its
credential cache file format.  The last time MIT krb5's format changed
was in 1995(*), and we are unlikely to change it again without serious
consideration for compatibility on the part of all implementations.
Part of the reason we haven't formally documented it is that Simon did
it for us in the Shishi documentation.  (It would certainly be better if
it were specified as part of our own documentation, or in some kind of
neutral implementation standard document; that's just a matter of
resources and priorities.)

(*) Support for "configuration values" was added a couple of years ago.
This is technically layered on top of the file format, but does affect
code which lists a ccache.  Heimdal implemented this first and MIT krb5
followed its lead.

> Is there KCM for MIT? Are MIT and Heimdal KCM compatible on the wire? Can
> KCM be usable without being root on a multiuser machine? May the source
> be with me...

There's no KCM for MIT krb5 as yet.  A complicating factor is that MIT
krb5 already has a daemon-backed ccache on Windows and OSX called CCAPI,
as well as past plans (never finished) to port it to Unix.

MIT krb5 does have Linux kernel keyring support, but of course that
would be restricted to a single kernel.