On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote: > On Feb 28, 2009, at 12:43, Theodore Tso wrote: > > It might be possible to dispatch on krb5_keyblock->magic to determine > > whether it the new fields are there, and in places where a passed in > > krb5_keyblock is allocated on the stack, the called function could > > allocate a new-style krb5_keyblock and import the key. (How many such > > places are there? I didn't think there would be that many.) It > > wouldn't be that pretty, yes, but if it's considered important to > > preserve the ABI, it's probably doable... > > Yeah, that's been considered. It's a little risky in that sometimes > the "magic" field just isn't initialized (especially in an application- > provided keyblock), and adding a dependence on it (at least on it
Actually, is it ever initialized when allocated on the stack? I suspect not. It's been pointed out to me that it's not necessary to change krb5_keyblock just to use OpenSSL, and I think one could argue the same for PKCS#11. However, leaving krb5_keyblock unchanged is sub-optimal, and, most importantly for performance, means you can't cache derived keys in the keyblock itself (you could have a hash table). > *not* having a certain 32-bit value that indicates the extended form) > would be a minor ABI change. I think the risk is probably low, and > it'd probably be worth the extra ugliness to get the benefits. > > We'd also still need to handle the krb5_keyblock structure embedded in > krb5_creds; in that instance it wouldn't be extensible. > > It'd be so nice to be able to do a new API for a v2.0 someday. :-) Yes. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
