mit-krb5 thread support -- fork safety
Wyllys Ingersoll
wyllys.ingersoll at sun.com
Wed Apr 21 14:24:15 EDT 2004
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
More information about the Kerberos
mailing list