mit-krb5 thread support -- fork safety

[Wyllys Ingersoll]

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.


thanks,
  Wyllys