Bug#563253: With nss 3.12.5, evolution does not know about _any_ certificate authorities

[Sam Morris]

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?

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
      * 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

> 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.

> Cheers,
> 
> Mike

Thanks for the diagnosis! :)

-- 
Sam Morris <sam at robots.org.uk>