mit-krb5 thread support -- fork safety

Sam Hartman hartmans at MIT.EDU
Tue Apr 20 12:31:00 EDT 2004

I know that I object to krb5_keyblock becoming invalid after fork.
It's not particularly opaque and by definition, there is enough
information in the keyblock for the crypto library to get it working
again even if it needs to destroy memoized state.

As a side note we really should work on caching key schedules in MIT
Kerberos.  I realize Sun has done this, but as discussed, they have
done so in a manner we cannot duplicate or accept.


More information about the krbdev mailing list