[30769] in Kerberos
Re: FIPS certification
daemon@ATHENA.MIT.EDU (Theodore Tso)
Sat Feb 28 12:45:21 2009
Date: Sat, 28 Feb 2009 12:43:48 -0500
From: Theodore Tso <tytso@MIT.EDU>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Message-ID: <20090228174348.GB6935@mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20090228060146.GX9992@Sun.COM>
X-SA-Exim-Mail-From: tytso@mit.edu
Cc: kerberos@MIT.EDU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@MIT.EDU
On Sat, Feb 28, 2009 at 12:01:46AM -0600, Nicolas Williams wrote:
>
> Solaris at the time did not expose a krb5 API, so it was trivial for us
> (Wyllys) to change krb5_keyblock and to add initializers for it. But
> when it comes to contributing these changes to MIT we'll run into this
> problem. There are solutions that preserve compatibility with code that
> allocates krb5_keyblock on the stack, but they aren't pretty. Breaking
> the ABI could be considered -- it'd be a smallish break, but it won't be
> Sun deciding that, but the MIT Kerberos community.
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...
- Ted
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
