[kerberos-discuss] thoughts/issues making MIT krb code fit for drop-in to Solaris

Jeffrey Altman jaltman at secure-endpoints.com
Thu Sep 18 21:47:30 EDT 2008

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://mailman.mit.edu/pipermail/krbdev/attachments/20080918/1aa8475b/attachment.bin

More information about the krbdev mailing list