On Thu, Dec 15, 2005 at 10:09:07PM -0800, Russ Allbery wrote: > 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. Right. Is there any reason not to override the urgency immediately on libapache-mod-auth-kerb? Makes no difference for KDE, actually; even though binNMUs have expedited the process immensely, it will still take some time to get all of the packages in order. Just having krb5 as a candidate now helps, so we can get a look at what britney says is still outstanding; I've added some hints to this effect that will run tomorrow. > 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. Niiiice. :) > 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. I think I would have to call this !RC; certainly if it's not reproducible it doesn't seem worth holding the update out of testing for, and even if it is reproducible it seems to me that using nscd is really the only sane way to use nss_ldap these days. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature