krb5 and KDE
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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: