krb5-1.8-beta2 is available

[Marcus Watts]

> Date:    Tue, 02 Mar 2010 08:55:28 EST
> To:      Marcus Watts <mdw at umich.edu>
> cc:      Tom Yu <tlyu at mit.edu>,  krbdev at mit.edu
> From:    Sam Hartman <hartmans at mit.edu>
> Subject: Re: krb5-1.8-beta2 is available
> 
> >>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:
> 
>     Marcus> If you ask me, 1.8.1 might be a good time to put this in.
>     Marcus> Then again, I'm surprised this didn't go in years ago, so I
>     Marcus> might not be the best person to ask when such a feature
>     Marcus> should go in.  (options to selectively enable
>     Marcus> des,des3,rc4,aes would be a nice generalization.)
> 
> 
> There's a big problem with build-time options and that is that you run
> into trouble where one build of krb5 doesn't function the same as
> another.  Particularly because we're providing libraries for OS
> distributions, this can be a big problem.  It might be OK in some
> embedded environment to subset krb5.  We definitely don't want Redhat
> and Ubuntu shipping a different subset especially if it affects the ABI
> that is exposed.
> 
> I think these issues can be managed.  I think that if we write down some
> rules for when configure-time options are appropriate and guidance for
> packagers on what they should do with these options, we can move
> forward.
> 
> I also think disabling a cryptosystem is probably fairly harmless
> provided that it does not change the exported symbols from libk5crypto.
> In particular, I'd still expect that a GSS-API library built one way
> would work with a crypto library from the same version of krb5 built the
> other way.  So, even changing the internal symbols would be bad.
> 
> --Sam

I actually *want* to see those internal symbols disappear if
the corresponding crypto system goes away.  That's one of the
areas of unintended crypto dependency that I want to trap.
I'm not particularly inspired by the idea of exporting symbols
that point to functions that aren't implemented.  This means
instead of having ld.so report that some function isn't there,
the application is expected to somehow detect at runtime that
the function is broken.  I don't think this is actually helpful.

The actual interface exported by libk5crypto.so is *mostly*
crypto-clean, so I don't think we're actually talking about
a major problem.  So, at a quick glance, here's what I see:

des
	mit_des_fixup_key_parity	kdc
	mit_des_is_weak_key		kdc
des3
	krb5int_enc_des3		"no ref"
rc4
	krb5int_arcfour_gsscrypt	krb5.so
	krb5int_enc_arcfour		"no ref"
rijndael
	krb5int_aes_encrypt		"no ref"
	krb5int_aes_decrypt		"no ref"

"no ref" means I can't find any references from other
shared libraries in 1.8, nor any reference in krb5-appl-1.0-alpha1

I think there are 4 cases here:
/0/ internal uses.
/1/ gssapi needs.
/2/ testing
/3/ external application support

In terms of des, cases 1 and 2 don't matter.  The kdc reference
looks trivial to fix, if it matters.  Looks like the main problem is
application dependencies on our old friends, mit_des_is_weak_key and
mit_des_fixup_key_parity.  That's exactly what I want to see "breakable".
Since you've been discouraging use of such symbols for some time, just
removing those symbols for all cases might be quite adequate.

Distribution-wise, I think the right packaging concept would be
"pure kerberos crypto w/o DES", and "kerberos crypto w/DES
for archaic applications".  Applications that require DES
can require the DES flavor of k5crypto.  An obvious and
attractiev case is going to be the kdc.  Making your environment
des free then becomes a matter of replacing all packages that
have DES dependencies.  Of course, once your KDC doesn't support DES,
then you have less reason to install application-side support that
requires DES in the first place.  It would be interesting to know
how many distribution packages are likely to need such dependencies.
The number could be quite small.

For the general case, well, I think the first question to
answer is how many of those things actually need to be exported.

A possible solution for the general case would be to make the entirely
crypto framework plugable.  That is, each crypto subsystem could be its
own separate .so, and k5crypto can become a library to host shared logic,
load the plugable modules, and export the generic interface.  That's a
much bigger change.  Maybe 1.9?

				-Marcus Watts