[Pkg-samba-maint] krb5 transition: upgrading to krb5 1.6.1

[Sam Hartman]

Hi, folks.

I've just uploaded krb5 1.6.1 to experimental.  This is a new version
with enhanced plugin support, support for realm referrals, support for
storing Kerberos credentials in the Linux keyring rather than on disk,
and generally improvements all around.  The one big feature that is
missing from the Debian packages is support for the LDAP database
backend; that's missing because it requires LDAP 2.3.

I'd like to upload this to unstable.  It will involve a library
version bump; the new libraries are backward but not forward
compatible.  That is,existing software in Debian that uses public APIs
and is linked against the old version is expected to continue to work,
but new APIs are introduced so software linked against the new
libraries may not run against the old libraries.  In other words, no
soname change, but shlibdeps get bumped.

This is your chance to make sure that your software works against the
new version of Kerberos before it makes its way into unstable.  This
is also your chance to work with me if you're concerned about timing
of a shlibdeps change for krb5.



Samba is of particular concern because from time to time Samba has
used internal APIs and so it breaks when these APIs change.  I will
not consider it a bug in the krb5 package if internal APIs changing
breaks something, although I'll be happy to add conflicts as
appropriate.  I'll also be happy to try and work with you to figure
out how to fix your package if it is using internal APIs.  The public
APIs are anything in headers installed by libkrb5-dev without defining
KRB5_PRIVATE.



I'm aware of one issue that impacts nfs-utils.  Bug #413838 describe a
problem where if your server has a common misconfiguration the 1.6
Kerberos libraries on the client will cause mounts to fail.  In
particular, the kernel only supports DES encryption for NFS.  However,
many servers are keyed as if they support more modern encryption such
as AES.  The client tries to request that only DES be used, but this
has been broken in 1.6.  So, Kerberos negotiates AES or some other
strong encryption and then the server tries to feed this to the kernel
and fails.  This is a bug and MIT will definitely fix it, but I don't
think this should hold up an upload to unstable.  There is a work
around: properly configure the server.

Comments are welcome.

--Sam