On Fri, Jan 08, 2010 at 04:51:03PM +0000, Sam Morris wrote:
> On Thu, 2010-01-07 at 10:03 +0100, Mike Hommey wrote:
> > On Wed, Jan 06, 2010 at 05:43:35PM +0000, Sam Morris wrote:
> > > On Wed, 2010-01-06 at 18:10 +0100, Mike Hommey wrote:
> > > > On Wed, Jan 06, 2010 at 05:06:08PM +0000, Sam Morris wrote:
> > > > > On Wed, 2010-01-06 at 17:39 +0100, Mike Hommey wrote:
> > > > > > On Wed, Jan 06, 2010 at 02:22:32PM +0000, Sam Morris wrote:
> > > > > > > I just noticed that, when I downgrade to NSS 3.12.2, evolution
> > > > > > > populates
> > > > > > > its certificate authorities list (edit -> preferences ->
> > > > > > > certificates ->
> > > > > > > authorities). If I upgrade to 3.12.5, run 'evolution
> > > > > > > --force-shutdown',
> > > > > > > then re-run evolution, the certificate authority list is empty.
> > > > > >
> > > > > > Can you run evolution under strace -eopen and send the output here ?
> > > > > > That could well be due to changes to the debian changes that
> > > > > > happened in
> > > > > > 3.12.5.
> > > > >
> > > > > This call:
> > > > >
> > > > > open("/usr/lib/nss/libnssckbi.so", O_RDONLY) = 21
> > > > >
> > > > > is present with the old NSS, but not the new. The strace output is
> > > > > attached in case it's something else.
> > > >
> > > > mmmm maybe stat,lstat and others would be needed too. Could you just
> > > > send a full strace ?
> > >
> > > Here you go.
> >
> > Thanks.
> >
> > I have identified what i think is only one part of the problem. It is due
> > to a change in our Debian changes. The previous changes would load
> > /usr/lib/nss/libnssckbi.so if trying to load a non existing
> > libnssckbi.so. The new version would only load /usr/lib/nss/libnssckbi.so
> > if asked for "libnssckbi.so" without a path. What I will try to do is to
> > still allow loading /usr/lib/nss/libnssckbi.so when detecting the
> > wrongly populated secmod.db (due to previous behaviour).
>
> Great! Based on the strace output I tried symlinking libnssckbi.so into
> ~/.evolution and found that it works around this bug quite nicely.
>
> > What i think is the other part of the problem is that evolution tries to
> > find libnssckbi.so itself before giving it to libnss.
>
> Is it wrong to do so? Or is the method for locating libnssckbi.so a grey
> area?
Yes it is. A huge grey area.
> I notice that evolution looks in MOZILLA_NSS_LIB_DIR which is populated
> from the libdir variable in nss.pc. On Debian, of course,
> that's /usr/lib. What about one of:
>
> * if it's never correct for /usr/lib/libnssckbi.so to exist on a
> Debian system, modifying NSS to open /usr/lib/nss/libnssckbi.so
> when an application asks for it
The problem is that evolution first checks if the file exists, before
even asking NSS.
> * adding a Debian-specific variable in nss.pc that points
> at /usr/lib/nss and patching Debian packages to use it when
> locating libnssckbi.so
> * patching Debian packages to open "libnssckbi.so" with that exact
> name, and not try searching for it themselves
That's actually the best course of action IMHO, especially considering
the current patch we have against NSS does handle "libnssckbi.so" by
trying a standard dlopen (which means it will try LD_LIBRARY_PATH), and
then will try the nss directory relative to wherever libnss3 itself is
located. (and this is what has been recommended by NSS upstream). This
is even more going to be important to do this when multiarch will be
supported, and libnssckbi.so may be in a multiarch directory, i.e. not
necessarily in /usr/lib/nss.
Obviously, that will only work for new profiles. I still need to fix NSS
for existing broken profiles. Now that I have all the information I
need, I'll come up with a patch soon(ish). I'll also provide a patch for
evolution and will try to check the other NSS-using applications.
Note there will be another change after squeeze which implies deeper
changes to NSS handling in these applications.
> > If you give evolution a new profile, is the certificate list populated in
> > the new
> > profile under nss 3.12.5 ?
>
> It is not populated in this case.
That's what I was afraid of.
Mike
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
