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

[Mike Hommey]

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

What i think is the other part of the problem is that evolution tries to
find libnssckbi.so itself before giving it to libnss. If you give
evolution a new profile, is the certificate list populated in the new
profile under nss 3.12.5 ?

Cheers,

Mike