On Tue, Nov 27, 2001 at 01:14:31PM -0800, Booker C. Bense wrote: > On Sat, 24 Nov 2001, Mayers, Philip J wrote: > > > As my follow up indicated (which of course you read), I do realise that a > > client doesn't have the service key - I wasn't thinking when I typed the > > mail and it was a stupid question. > > > > I could give many flippant, impolite answers to your first question, but > > instead I'll say: Why not? Are you so sure that the MIT or Heimdal > > implementations are so perfect that there's nothing I can contribute by > > making a third interoperable one? If so, I envy your confidence. > > > > - I think what Sam was trying to tell you was that your code won't be > interoperable. The file ccache format that MIT is currently using is > not meant to be a "public" format and can be changed at any time. In > fact it will be changed in the near future. You're supposed to use > the API to access it. I think Sam is well aware of the flaws of > kerberos and wishes people that had time to work on it would work on > fixing the existing code, rather than redoing all the same old errors > in a different code.
A) I think a High Level Language implementation of Kerberos V would be great to have B) Wouldn't it be nice the ccache stuff were in a separate library so that one could use that library without having to use all of libkrb5? But (B) would certainly require changing the API as the ccache functions expect libkrb5-specific structs/defines/whatever and are heavily intertwined with libkrb5. Since there is no standalone ccache or keytab or replay cache API, I think anyone attempting an HLL implementation will have no choice but to implement his/her own ccache/keytab/replay cache. Either that or use some Foreign Function Interface... but that has its own problems. Since Phil Mayers seems to be working on a Python implementation of Kerberos V and he probably doesn't want to just make Python bindings to the MIT or Heimdal APIs, he probably has no choice but to do his best to support the MIT ccache format. > - You may not be familiar with the history of kerberos, but it is rife > with just slightly incompatible API's that have put up huge roadblocks > to interoperablity and code exchange in the past. Of course that never > stopped anybody before and I don't expect it to now. Well, we could start with an API definition. But it's probably too late now as MIT and Heimdal differ sufficiently to cause some pain. > - Booker C. Bense Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
