Nicolas Williams wrote: > The Solaris libkrb5 ABI *is* different from the MIT krb5 ABI when MIT > krb5 is built on Solaris. But that doesn't mean that we must break MIT > krb5 compatibility. > > It would mean having a ./configure option to select which ABI you want. > When building MIT krb5 to provide system components for OpenSolaris > you'd use the Solaris ABI, otherwise you'd use the default ABI. > > (The alternative is that we never bother doing this drop-in thing. Or > that we break the Solaris krb5 ABI and find a very different way to > solve the problems with krb5_keyblock.) > > Nico
The long term solution to the KFW problem is to develop an API/ABI that Microsoft can safely implement as a shim on top of their internal implementation. To make that happen all of the key data and other privates must remain hidden from the application. Adopting the Solaris ABI would be a good first step in that direction. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/kerberos-discuss/attachments/20080918/1aa8475b/attachment.bin>
