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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
