building Kerberos libraries for PalmOS

Ken Raeburn raeburn at MIT.EDU
Tue Feb 17 13:39:11 EST 2004

I'm interested in this too, but haven't had time to really pursue it 
much.  A few things do come to mind:

It'll need to be a multisegment app or library; the code space will be 
*way* too large for a single segment.

I think there's some debugging code that writes to stdout or stderr.  
You'll probably want to comment it out.

The PalmOS development package doesn't have all the standard C header 
files.  Some code may need new conditionals that aren't already there.  
Alternatively, you could drop in fake versions of some standard C 
headers that include the appropriate ones from the PalmOS dev kit.

You'll need to create the equivalent of the include/krb5/autoconf.h 
file that gets generated on UNIX, or the win-mac.h file currently used 
only for Windows.

Some of the crypto code (AES comes to mind) has simple preprocessor 
options that will reduce the code/data size, at some cost in speed.  
You'll probably want to use those.  Changing DES, MD4, MD5 and SHA-1 to 
generate smaller code is also not hard, but requires some actual code 
changes; I've started on some of those, and may get them checked in (as 
options) for the 1.4 code base.  Haven't really looked at RC4.

MIT Kerberos 1.3 assumes that getaddrinfo() is available for name 
lookups, and if not, fakes it with a static function to implement it in 
each object file using it.  For the platforms we support, most have 
getaddrinfo already, and one old one that we're probably on the verge 
of de-supporting (just my guess, we haven't made any decisions) loses 
several kilobytes of code space in each of several object files to fake 
it.  The PalmOS libraries don't have getaddrinfo, and including the 
support code as is will add quite a bit of code.  We'll probably be 
moving it to a separate support library for 1.4, and possibly adding 
more caching of results.

The credentials cache needs to be handled differently.  Perhaps an 
in-memory cache (for a single application getting tickets and using 
them and discarding them on exit), or a Palm database file (presumably 
marked not for backup).

You probably don't care about the code for supporting application 
servers -- the replay cache support, keytab support, code for 
decrypting AP-REQ messages and encrypting AP-REP messages, some of the 
GSSAPI code, etc.  From what I've seen, CW wants you to add each file 
separately, so you can just leave out a bunch of them, though offhand I 
don't have a list.  Or, if you just add everything, and get it all to 
compile, the linker should leave out unneeded parts of an archive 
library when building an executable.

We've got recursion and large stack frames in places, and PalmOS apps 
have fixed, generally small stack sizes.  Some of the stack frames 
could undoubtedly be made smaller, and the recursion cases might be 
converted to iteration without a huge amount of difficulty, but they 
have to be found, first.  (I've got some ideas on tweaking GCC for 
PalmOS so as to provide some of this information.)

Long-term memory management on the Palm is supposed to be done through 
MemHandle objects, instead of through malloc and free.  These handles 
allow PalmOS to shift memory around while objects aren't being actively 
referenced, to counter fragmentation.  The MIT Kerberos code isn't set 
up for this sort of indirection.  You can use malloc and free, but your 
application might run out of memory faster.

The config data, currently stored in krb5.conf, needs to be put 
somewhere.  A database might be one option, but you'd have to replace a 
lot of the profile library code for accessing it.  A memo with a magic 
first line of "krb5.conf" is another sort of approach I've seen used; 
just look for the memo and parse the body as the contents of the file 
would be parsed.  We've made some changes towards being able to work 
without a krb5.conf file at all, but we're not completely there yet, 
and there are some security issues that need to be considered.

I've written up some code for finding the local network addresses, as 
an experiment in dealing with PalmOS code.  That functionality is 
needed for the Kerberos library; I'll see if I can dig up my sample 

As you might gather, I don't believe this will be a trivial project.

Personally, I'm more interested in seeing it happen in a way compatible 
with the GNU tools, in part because maintaining data for multiple build 
systems means more work, and partly because I'm a free software guy and 
I've done development work on the GNU tools.  But the GNU tools for 
PalmOS have a few problems.

Would MIT accept code changes related to this?  Maybe, if they're clean 
and general enough.  Changes to a huge number of source files (e.g., 
the section annotations that would be needed for functions if we used 
the GNU tools for PalmOS, which otherwise would be my preferred 
approach) wouldn't be very desirable.  Clean changes implementing an 
"optimize for code size" option might be okay.  Other changes...I don't 
know, but we can talk about them.

On Monday, Feb 16, 2004, at 15:19 US/Eastern, Chaitanya Desai wrote:
> Hi,
> I am trying to build kerberos libraries for PDAs (Palm OS in 
> particular).
> My goal is to have library/libraries defining functions that simple
> applications that run on PDAs can call into.
> I am using Codewarrior for Palm as the IDE. Any suggestions on where I
> could start would be greatly appreciated.
> Sincerely,
> Chaitanya Desai.
> _______________________________________________
> krbdev mailing list             krbdev at

More information about the krbdev mailing list