Kerberos vendors

[Ken Raeburn]

"Gabe" <gabe at nospam.net> writes:
>   In particular, I'm looking for Kerberos libraries for the
> PocketPC or PalmOS platforms, but knowing the existence of any vendors would
> probably be better than nothing.

I'm not aware of anyone shipping Kerberos for either.

I can't speak to PocketPC at all, but some months back I tried making
a start at building MIT Kerberos with PalmOS tools.  Since (a) the GCC
tools for PalmOS would require hacking *lots* of source files to put
in section declarations for most functions, and (b) CodeWarrior
doesn't seem too friendly to big projects already set up using make,
apparently needing you to add each file again through the GUI (unless
I've missed something, which is entirely possible, I'm very new to
CW), I didn't get very far.

I've been talking with Jeff Hutzelman about some possible hacks to the
GCC toolchain and *small* hacks to the MIT code to let us build a krb5
application more easily, but I don't know if or when I'll get time to
implement any of them.

A new implementation and new API would have some advantages, like
being able to use MemHandles instead of locking down lots of tiny
objects at fixed locations so the memory management system couldn't
move them.  Though it occurs to me that some aspects of this --
namely, the Lock, Access, Unlock sequence -- is not terribly much
unlike some of what we need for thread safety...but the desired
interfaces are probably very different.  The PalmOS memory lock
function takes a MemHandle and gives you back a pointer to the object,
which is only valid until the unlock call, after which the object may
move again.  In the krb5 case, we may want one mutex protecting a
linked list, in some cases.  (Hm, perhaps ordered-list and iterator
objects, defined in a system-specific way....)  I don't have any
familiarity with PocketPC to generalize this to what it might prefer
for optimal resource usage.  Fortunately, at the library-building
level, we wouldn't need to worry much about UI or threading issues.
(A little, not much.)

Ken