Here's the summary of where we're at. krb5 is currently blocking KDE, as well as a few other things. I've closed the bug to keep it out of testing, as most of the details have now been sorted out.
The new krb5 package doesn't change SONAMEs, but it does remove some internal symbols that were never prototyped and weren't supposed to be used. For the most part, nothing cared, but there are a small handful of packages that were affected. One was libauthen-krb5-perl, which has been fixed and which is also ready to migrate to testing. It will need to get hinted in with krb5, I believe. libapache-mod-auth-kerb was doing really nasty things with Kerberos library internals that broke horribly with 1.4. A new version has *just* been uploaded that replaces that code with code that's specific to 1.4 but disables the replay cache in a far saner way. I'm guessing that KDE doesn't *really* want to wait ten days for libapache-mod-auth-kerb to age in, but it should be able to be pushed sooner. I've tested the new package myself and can confirm it works fine with 1.4 now, with and without credential passing. This is the only thing blocking krb5 and all related packages from going into testing right now, as near as I can tell. (I'm guessing that this is the first time that libapache-mod-auth-kerb held up a KDE transition.) A Debian user *has* found yet another odd interaction between Kerberos and OpenLDAP (I can see Steve groaning already). comp.protocols.kerberos has the thread; it's not in the BTS yet, in part because I don't really understand what's going on. Kerberos upstream is actively investigating. The problem relates to running kinit while using LDAP in nsswitch, and as near as we can tell, goes something like this: * User runs kinit. * Kerberos library initializes, sees no pthreads, doesn't init mutexes. * kinit does getpwuid. * libc dynamically loads LDAP nsswitch. * LDAP nsswitch loads OpenLDAP libraries. * OpenLDAP libraries pulls in pthreads. * Kerberos library goes to write to the ticket cache, sees threads, uses a mutex lock. * Mutex function gets called with uninitialized memory, weirdness ensues. The thing is, there's code in Kerberos specifically to *keep* it from doing this by setting a flag if it initialized without pthreads that's supposed to keep it from ever using pthread-related mutexes later. It seems that this is not working for some reason for this particular user, maybe. I'm not sure if this is sufficiently critical to warrant an RC bug, and in fact I'm not even sure where the bug is yet, although it's looking more and more like it's in the Kerberos libraries. But if the above sounds scary, you may want to *not* bump the urgency of libapache-mod-auth-kerb just yet and see if an RC bug ends up materializing on krb5. If it does, with a patch, I can do another krb5 upload on short notice; I'll be around all this weekend and next week. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
