mit-krb5 thread support -- fork safety
wyllys.ingersoll at sun.com
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