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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.