Re: documentation vs specification (was:Wishlist: credential file update/access collision avoidance?)

Hello Rune,

Most of what I've seen in this discussion can't be solved with neither of file caches or file keytabs, documenting more about existing formats wont help much.

The standalization for that happening for kerberos is on the wire format, and I think that is a good thing, it allows for innovation in implementations with having to deal with legacy.

For example, the heimdal database format is asn1 encoded entries using our compiler, while MIT uses psudeo xdr encoded entries.

Love


3 okt 2011 kl. 15:29 skrev <[email protected]>:

> Hello Love,
> 
> Thanks for the pointers to the documentation.
> 
> On Mon, Oct 03, 2011 at 09:51:33AM +0000, Love Hörnquist Åstrand wrote:
>> I would happy accept more documentation, starting points are the info docmentation and doxygen
> 
> The problem is what it is "to be documented". All we have to document
> is an implementation (or two-three ones). Unfortunately certain crucial
> data is missing which should actually predate an implementation.
> 
> The goals of Heimdal stated in https://github.com/heimdal/heimdal/wiki/
> do not even mention "be ccache-file-format-compatible with MIT" (note
> that an API compatibility is a very different thing).
> 
> I am running a mix of applications linked to different versions of MIT
> and different versions of Heimdal. Thanks Heaven they understand each
> other's ccaches and keytabs - but it is apparently not guaranteed (!)
> 
> Is there any specification of ccache format separate from the source of
> *_cc_* functions?
> 
> I have found an answer:
> 
> http://www.gnu.org/s/shishi/manual/html_node/The-Credential-Cache-Binary-File-Format.html
> 
> states:
> "Like the MIT keytab binary format (see Michael B Allen's reverse
> engineered description in keytab.txt), the credential cache format is
> not standard nor documented anywhere."
> 
> You see. We are at the mercy of implementations reverse-engineering
> each other... Note that applications using different implementations do
> not only talk the "network protocols" to each other, they do share the
> keytabs and the credentials cache files.
> 
> The use of files for interprocess communication (as ccache) does not
> make this communication free from the need of a rigorous definition,
> as rigorous as for communication across a network. Communication remains
> communication: we can not assume identical implementation "on the other
> side" and we must assure the presence of a compatible one.
> 
> How many system architects realize that there is no formal specification?
> How reliable is the fact that MIT and Heimdal can share the data? Is it
> reliably working today? Will it tomorrow? What about shishi? What if
> I decide to reimplement Kerberos, how can I stay interoperable?
> 
> It is plain unwise that part of the protocols remain undefined
> (and are being reverse-engineered) even today. This is not a matter of
> documentation, this is a matter of a missing specification.
> 
> I hope there are people here familiar with standardization processes
> who would suggest a way to fix this awkward situation.
> 
> The original question "how to handle ccache reliably" can not be
> answered at all, unless we either 1. have an implementation-independent
> definition of ccache format and semantics or 2. assume that all
> applications sharing kerberos-related data use One True Implementation.
> 
> The second assumptions is not true, and it is actually Heimdal who first
> broke it. I guess even MIT people would now be inclined to follow the
> reality and agree on a properly written keytab/ccache interoperability
> standard? (a format _and_ semantics/behavior at concurrent access).
> 
> Regards,
> Rune
>