[15544] in Kerberos_V5_Development
Re: krb5-1.8-beta2 is available
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Mar 2 08:55:31 2010
From: Sam Hartman <hartmans@mit.edu>
To: Marcus Watts <mdw@umich.edu>
Date: Tue, 02 Mar 2010 08:55:28 -0500
In-Reply-To: <E1NlANg-0002YJ-1C@bruson.ifs.umich.edu> (Marcus Watts's message
of "Fri, 26 Feb 2010 19:18:04 -0500")
Message-ID: <tslocj6vne7.fsf@mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu, Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>>>>> "Marcus" == Marcus Watts <mdw@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
