mit-krb5 thread support -- fork safety

Wyllys Ingersoll wyllys.ingersoll at
Wed Apr 21 12:06:56 EDT 2004

Sam Hartman wrote:

>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.

Remind me again what we did that was not going to work for MIT?
I know we talked about it before, but I can't recall the
outcome of the conversation.


More information about the krbdev mailing list