thoughts/issues making MIT krb code fit for drop-in to Solaris

[Ken Raeburn]

On Sep 17, 2008, at 20:04, Will Fiveash wrote:
> One goal Sun has in regards to it's association with the MIT Kerberos
> Consortium is to eventually have the Consortium's Kerberos source code
> made suitable to use as is in Solaris (drop-in).  This would save Sun
> time and effort in that resync'ing the Consortium's source code with  
> the
> Solaris Kerberos source code could be avoided.


Overall, I think it's a good idea for us to incorporate changes that  
improve the library for everyone, or make it easier to integrate  
without making it harder for us to maintain.  On first read-through,  
here are some of my initial observations:

> One approach suggested by Nico Williams is to do this by modifying one
> MITKC component at a time to keep each project smaller in scope.  The
> following components would be updated in an order like:

Seems reasonable...

> - Crypto Framework
>
>    Solaris Kerberos uses the native Solaris Encryption Framework
>    interfaces for it's crypto needs in both user and kernel space.
>    This mainly involves changes to files under src/lib/crypto. Note
>    that the _krb5_keyblock has also been modified:

I believe our intent from the introduction of krb5_init_keyblock was  
to move towards dynamic allocation of keyblock structures in the  
library, which structures would be extended with additional fields not  
visible to the caller; other code would distinguish the two kinds via  
the magic number field.  Allocating the structure in the caller would  
probably be considered deprecated (but still supported, for backwards  
compatibility).  Additional fields could include key schedules, cached  
derived keys, stuff like that.

We haven't really pushed forward on the idea beyond introducing the  
new allocation function.

> - I18N, error tables and messages in general.
>
>    MIT dynamically generates their error tables, Solaris uses a static
>    switch statement in various C files based on the MIT error tables.
>    For example, in OpenSolaris there is this code in
>    usr/src/lib/gss_mechs/mech_krb5/et/chpass_util_strings.c:

The KfM code already has i18n support in the error table handling, so  
ideally we'd extend the UNIX com_err code in a similar fashion.   
Handling of the domain names is an interesting question -- since  
error_message needs to figure out the right domain name to use, and  
error tables in different libraries may have been installed by  
different packages (it's not widely used, but there are other things  
besides krb5 using com_err), the domain name probably needs to be  
independent of the library and associated just with the error table  
name or values, unless we want to require use of brand new com_err APIs.

>    Also Solaris calls gettext() to translate various non-error table
>    messages.  Anyway, this is an area that we need to research further
>    to find a reasonable solution.

Yeah.  I'm not sure what the best answer's going to be for Windows,  
where (from a couple of things I've read) I think the LoadString  
function is the usual interface, but it wants an integer key, not a  
string, and the domain-name equivalent is a module handle returned  
from another function call.  But otherwise I think gettext, or a  
wrapper around it (to allow for indirection to other mechanisms, or  
filling in no-ops for lame systems or for intentionally disabling it),  
is probably going to be the answer we want.

> - Zero Conf realm lookup changes
>
>    Support of a fall back default realm based on the host's domain  
> name
>    if the default realm is not specified in the krb5.conf.

Yes, we were talking about this the other day.  I think the patch I  
was remembering that Mark sent in does something a bit different  
though.  I still should see about pulling some of that code in though.

> - No reverse DNS lookup in krb5_sname_to_principal()

*sigh*

This will be a behavioral change.  We should also not be doing the DNS  
lookup to canonicalize the name in the first place, but fixing that  
requires other support (having the KDC recognize aliases, etc); that  
will also be a behavioral change.  I think we've been maintaining the  
status quo until we can inflict just one massive change on the end  
sites instead of two.

Ken