mit-krb5 thread support -- fork safety

[Wyllys Ingersoll]

Sam Hartman wrote:

>>>>>>"Wyllys" == Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:
>>>>>>            
>>>>>>
>
>
>    Wyllys> Remind me again what we did that was not going to work for MIT?
>    Wyllys> I know we talked about it before, but I can't recall the
>    Wyllys> outcome of the conversation.
>
>You changed the krb5_keyblock structure which is part of our ABI.
>
>We created an initializer for krb5_keyblock.  OUr code can have an
>expanded krb5_keyblock structure with private data and can cache key
>schedules when the initializer and allocator are used, but cannot when
>the caller manages krb5_keyblocks themselves.
>  
>

OK, now I remember.  I'm going to take a look at your initializer
and allocator functions to see if we can use the same method.  I found lots
of places in the code where keys are manipulated in different ways,
so I didn't consider doing this originally.

Also, just a side note - we are not caching key schedules, our keyblock
has a list of derived keys so that the key derivation doesn't get
repeated, but key schedules are not explicitly cached.

-Wyllys