Debian Bug report logs - #563253
libnss3-1d: Fails to verify the certificate of my company email server

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libnss3-1d: Fails to verify the certificate of my company email server

Date: Fri, 01 Jan 2010 13:28:47 +0000

Package: libnss3-1d
Version: 3.12.5-1
Severity: grave
Justification: renders package unusable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since upgrading libnss3-1d to 3.12.5, I have been unable to connect to my
company's email server. Evolution gives me this dialog:

SSL Certificate check for imap.example.com:

Issuer:            serialNumber=88888888,CN=Go Daddy Secure Certification
Authority,OU=http://certificates.godaddy.com/repository,O="GoDaddy.com,
Inc.",L=Scottsdale,ST=Arizona,C=US
Subject:           CN=*.example.com,OU=Domain Control Validated,O=*.example.com
Fingerprint:       ec:cf:43:7f:87:84:f0:63:ec:b4:5d:60:e5:7e:6b:23
Signature:         BAD

No problem with iceweasel, thunderbird, etc. but they don't appear to use the
split-out package of NSS.

I reported the same bug against gnutls, #563127. The maintainer found that
gnutls refused to accept the certificate because it was issues by a "V1 CA".
Sadly I'm no X.509 expert so I don't know what that really means. The
certificate in question was issued in April 2009, so it's not exactly ancient.

Please tell me if you'd like the server address to debug this further yourself,
or whether there are any command line utilities for NSS that I can use as the
equivalent of gnutls-bin/'openssl s_client' to debug further. 

Because this coincides with the upgrade from 3.12.4 to 3.12.5 I am assuming
that NSS made a similar policy change to GnuTLS, to stop trusting V1 CAs. If
this is the kind of thing that a user of NSS can override, please let me know
and I'll forward that information to the (evolution) upstream bug at
<https://bugzilla.gnome.org/show_bug.cgi?id=605773>.

- -- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (430, 'testing'), (420, 'unstable'), (410, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libnss3-1d depends on:
ii  dpkg                   1.15.5.4          Debian package management system
ii  libc6                  2.10.2-2          GNU C Library: Shared libraries
ii  libnspr4-0d            4.8.2-1           NetScape Portable Runtime Library
ii  libsqlite3-0           3.6.21-2          SQLite 3 shared library
ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime

libnss3-1d recommends no packages.

libnss3-1d suggests no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAks9+IoACgkQshl/216gEHgbmgCg4/dEMui2RE3t+GgVJ9je7ouJ
AB0AmgOjth0/Cy2emJ/RkhIl56IzQ0Ec
=kMHW
-----END PGP SIGNATURE-----

Message #10 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Alexander Kurtz <kurtz.alex@googlemail.com>

To: Sam Morris <sam@robots.org.uk>

Cc: 561918@bugs.debian.org, 563253@bugs.debian.org, control@bugs.debian.org

Subject: Re: libnss3-1d: Fails to verify the certificate of my company email server

Date: Fri, 01 Jan 2010 16:58:00 +0100

[Message part 1 (text/plain, inline)]

merge 561918 563253
thanks

Hi,

I've got exactly the same problem here with Evolution 2.28 and my
Googlemail-Account. It is caused by bug #561918 [1]. You should check
my message there.

Cheers

Alexander Kurtz

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561918

Am Freitag, den 01.01.2010, 13:28 +0000 schrieb Sam Morris:
> Package: libnss3-1d
> Version: 3.12.5-1
> Severity: grave
> Justification: renders package unusable
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Since upgrading libnss3-1d to 3.12.5, I have been unable to connect to my
> company's email server. Evolution gives me this dialog:
> 
> SSL Certificate check for imap.example.com:
> 
> Issuer:            serialNumber=88888888,CN=Go Daddy Secure Certification
> Authority,OU=http://certificates.godaddy.com/repository,O="GoDaddy.com,
> Inc.",L=Scottsdale,ST=Arizona,C=US
> Subject:           CN=*.example.com,OU=Domain Control Validated,O=*.example.com
> Fingerprint:       ec:cf:43:7f:87:84:f0:63:ec:b4:5d:60:e5:7e:6b:23
> Signature:         BAD
> 
> No problem with iceweasel, thunderbird, etc. but they don't appear to use the
> split-out package of NSS.
> 
> I reported the same bug against gnutls, #563127. The maintainer found that
> gnutls refused to accept the certificate because it was issues by a "V1 CA".
> Sadly I'm no X.509 expert so I don't know what that really means. The
> certificate in question was issued in April 2009, so it's not exactly ancient.
> 
> Please tell me if you'd like the server address to debug this further yourself,
> or whether there are any command line utilities for NSS that I can use as the
> equivalent of gnutls-bin/'openssl s_client' to debug further. 
> 
> Because this coincides with the upgrade from 3.12.4 to 3.12.5 I am assuming
> that NSS made a similar policy change to GnuTLS, to stop trusting V1 CAs. If
> this is the kind of thing that a user of NSS can override, please let me know
> and I'll forward that information to the (evolution) upstream bug at
> <https://bugzilla.gnome.org/show_bug.cgi?id=605773>.
> 
> - -- System Information:
> Debian Release: squeeze/sid
>   APT prefers testing
>   APT policy: (430, 'testing'), (420, 'unstable'), (410, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages libnss3-1d depends on:
> ii  dpkg                   1.15.5.4          Debian package management system
> ii  libc6                  2.10.2-2          GNU C Library: Shared libraries
> ii  libnspr4-0d            4.8.2-1           NetScape Portable Runtime Library
> ii  libsqlite3-0           3.6.21-2          SQLite 3 shared library
> ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime
> 
> libnss3-1d recommends no packages.
> 
> libnss3-1d suggests no packages.
> 
> - -- no debconf information
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAks9+IoACgkQshl/216gEHgbmgCg4/dEMui2RE3t+GgVJ9je7ouJ
> AB0AmgOjth0/Cy2emJ/RkhIl56IzQ0Ec
> =kMHW
> -----END PGP SIGNATURE-----
> 
> 
> 

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Alexander Kurtz <kurtz.alex@googlemail.com>

Cc: 561918@bugs.debian.org, 563253@bugs.debian.org

Subject: Re: libnss3-1d: Fails to verify the certificate of my company email server

Date: Fri, 01 Jan 2010 21:17:04 +0000

[Message part 1 (text/plain, inline)]

unmerge 563253
thanks

On Fri, 2010-01-01 at 16:58 +0100, Alexander Kurtz wrote:
> I've got exactly the same problem here with Evolution 2.28 and my
> Googlemail-Account. It is caused by bug #561918 [1]. You should check
> my message there.

Hi Alexander, that does not appear to be the case for me. Setting
NSS_SSL_ENABLE_RENEGOTIATION=1 in the environment does not prevent the
verification failure.

I was careful to force shutdown evolution, then launch it afresh in case
the child e-d-s processes also required it to be set.

Regards,

-- 
Sam Morris
https://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[signature.asc (application/pgp-signature, inline)]

Message #24 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Alexander Kurtz <kurtz.alex@googlemail.com>

To: Sam Morris <sam@robots.org.uk>, 563253@bugs.debian.org

Subject: Re: libnss3-1d: Fails to verify the certificate of my company email server

Date: Fri, 01 Jan 2010 23:02:51 +0100

[Message part 1 (text/plain, inline)]

Hi,

Did you read my message? I said that downgrading helps, setting
NSS_SSL_ENABLE_RENEGOTIATION=1 didn't help me either. I can only guess,
but I think that's because Evolution is so deeply integrated into GNOME
that running
 NSS_SSL_ENABLE_RENEGOTIATION=1 evolution
simply isn't enough.

Would you be so kind to try downgrading libnss3-1d to the lenny version
and (if successful) re-merge the bugs?

Cheers

Alexander

Am Freitag, den 01.01.2010, 21:17 +0000 schrieb Sam Morris:
> unmerge 563253
> thanks
> 
> On Fri, 2010-01-01 at 16:58 +0100, Alexander Kurtz wrote:
> > I've got exactly the same problem here with Evolution 2.28 and my
> > Googlemail-Account. It is caused by bug #561918 [1]. You should check
> > my message there.
> 
> Hi Alexander, that does not appear to be the case for me. Setting
> NSS_SSL_ENABLE_RENEGOTIATION=1 in the environment does not prevent the
> verification failure.
> 
> I was careful to force shutdown evolution, then launch it afresh in case
> the child e-d-s processes also required it to be set.
> 
> Regards,
> 

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Alexander Kurtz <kurtz.alex@googlemail.com>

Cc: 563253@bugs.debian.org

Subject: Re: libnss3-1d: Fails to verify the certificate of my company email server

Date: Fri, 01 Jan 2010 23:11:39 +0000

[Message part 1 (text/plain, inline)]

On Fri, 2010-01-01 at 23:02 +0100, Alexander Kurtz wrote:
> Hi,
> 
> Did you read my message? I said that downgrading helps, setting
> NSS_SSL_ENABLE_RENEGOTIATION=1 didn't help me either. I can only guess,
> but I think that's because Evolution is so deeply integrated into GNOME
> that running
>  NSS_SSL_ENABLE_RENEGOTIATION=1 evolution
> simply isn't enough.
> 
> Would you be so kind to try downgrading libnss3-1d to the lenny version
> and (if successful) re-merge the bugs?

I'm pretty sure the lenny version works fine, since 3.12.4 also worked
for me until it was replaced by 3.12.5.

Other than that, I don't see the similarity between the two bugs. I am
not using a certificate to authenticate as the reporter of #561918 is,
but regular password authentication. I also don't have the problem when
connecting to the server with iceweasel (the same certificate is used by
the web server on the same machine)

> Cheers
> 
> Alexander

-- 
Sam Morris
https://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[signature.asc (application/pgp-signature, inline)]

Message #36 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>, 563253@bugs.debian.org

Subject: Re: Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server

Date: Wed, 6 Jan 2010 11:13:25 +0100

On Fri, Jan 01, 2010 at 01:28:47PM +0000, Sam Morris wrote:
> Package: libnss3-1d
> Version: 3.12.5-1
> Severity: grave
> Justification: renders package unusable
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Since upgrading libnss3-1d to 3.12.5, I have been unable to connect to my
> company's email server. Evolution gives me this dialog:
> 
> SSL Certificate check for imap.example.com:
> 
> Issuer:            serialNumber=88888888,CN=Go Daddy Secure Certification
> Authority,OU=http://certificates.godaddy.com/repository,O="GoDaddy.com,
> Inc.",L=Scottsdale,ST=Arizona,C=US
> Subject:           CN=*.example.com,OU=Domain Control Validated,O=*.example.com
> Fingerprint:       ec:cf:43:7f:87:84:f0:63:ec:b4:5d:60:e5:7e:6b:23
> Signature:         BAD
> 
> No problem with iceweasel, thunderbird, etc. but they don't appear to use the
> split-out package of NSS.
> 
> I reported the same bug against gnutls, #563127. The maintainer found that
> gnutls refused to accept the certificate because it was issues by a "V1 CA".
> Sadly I'm no X.509 expert so I don't know what that really means. The
> certificate in question was issued in April 2009, so it's not exactly ancient.
> 
> Please tell me if you'd like the server address to debug this further yourself,
> or whether there are any command line utilities for NSS that I can use as the
> equivalent of gnutls-bin/'openssl s_client' to debug further. 

There is one, but you would need to build libnss3 yourself (and get the
binary in mozilla/security/nss/cmd/vfyserv). If you'd prefer me to further
investigate, please report the server address.

> Because this coincides with the upgrade from 3.12.4 to 3.12.5 I am assuming
> that NSS made a similar policy change to GnuTLS, to stop trusting V1 CAs. If
> this is the kind of thing that a user of NSS can override, please let me know
> and I'll forward that information to the (evolution) upstream bug at
> <https://bugzilla.gnome.org/show_bug.cgi?id=605773>.

There is no such change that I can see related to trusting V1 CA
certificates.

Mike

Message #43 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 563253@bugs.debian.org

Subject: Re: Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server

Date: Wed, 6 Jan 2010 13:53:46 +0100

On Wed, Jan 06, 2010 at 12:31:34PM +0000, Sam Morris wrote:
> > Before I go all the way to install evolution, could you check if there
> > is a secmod.db file in your evolution folder or somewhere else it would
> > be using ? (you can try to check in a strace output, possibly). Same
> > question for key3.db and cert8.db.
> 
> These files do indeed exist, in ~/.evolution. If you just wanted to
> check where evolution stores its certificate information, you can skip
> the next paragraph. :) 
> 
> I needed to get access to my email for work, so I accepted evolution's
> certificate warning. This seems to add a _permanent_ exemption for the
> certificate, and evolution does not seem to have any UI for manipulating
> exemptions, leaving me unable to reproduce the problem on this computer
> any more. In order to try and remove the exemption, I deleted the
> cert8.db, key3.db and secomd.db files in ~/.evolution. Evolution happily
> recreated them, but they are empty; so now evolution doesn't know about
> _any_ certificate authorities at all. So I can't reproduce the bug on
> this computer any more (or connect to any SSL-using server without
> having to manually verify the certificate, argh)... the bug will still
> exist on my system at home, so if you want these files then I can pull
> them off there later this evening.

That would be useful, thanks. You can also try giving the database to
vfyserv (not sure if it needs to be the directory path, or if it needs
to include the secmod.db leaf), which should theorically make vfyserv do
the same thing as evolution.

Mike

PS: I'm Cc'ing the bug again to have all the above messages logged, with
your server address stripped off.

Message #48 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: Re: Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server

Date: Wed, 06 Jan 2010 13:52:12 +0000

On Wed, 2010-01-06 at 13:53 +0100, Mike Hommey wrote:
> On Wed, Jan 06, 2010 at 12:31:34PM +0000, Sam Morris wrote:
> > > Before I go all the way to install evolution, could you check if there
> > > is a secmod.db file in your evolution folder or somewhere else it would
> > > be using ? (you can try to check in a strace output, possibly). Same
> > > question for key3.db and cert8.db.
> > 
> > These files do indeed exist, in ~/.evolution. If you just wanted to
> > check where evolution stores its certificate information, you can skip
> > the next paragraph. :) 
> > 
> > I needed to get access to my email for work, so I accepted evolution's
> > certificate warning. This seems to add a _permanent_ exemption for the
> > certificate, and evolution does not seem to have any UI for manipulating
> > exemptions, leaving me unable to reproduce the problem on this computer
> > any more. In order to try and remove the exemption, I deleted the
> > cert8.db, key3.db and secomd.db files in ~/.evolution. Evolution happily
> > recreated them, but they are empty; so now evolution doesn't know about
> > _any_ certificate authorities at all. So I can't reproduce the bug on
> > this computer any more (or connect to any SSL-using server without
> > having to manually verify the certificate, argh)... the bug will still
> > exist on my system at home, so if you want these files then I can pull
> > them off there later this evening.
> 
> That would be useful, thanks. You can also try giving the database to
> vfyserv (not sure if it needs to be the directory path, or if it needs
> to include the secmod.db leaf), which should theorically make vfyserv do
> the same thing as evolution.

I just had the idea of creating a new user, setting up my evolution
accounts, and trying vfyserv:

        test@durandal:~$ /tmp/nss/nss-3.12.5/mozilla/security/nss/cmd/vfyserv/Linux2.6_x86_64_glibc_PTH_64_OPT.OBJ/vfyserv -p 443 -d ~/.evolution/ imap.example.com 
        Connecting to host imap.example.com (addr 217.160.200.53) on port 443
        PROBLEM WITH THE CERT CHAIN:
        CERT 3. info@valicert.com [Certificate Authority]:
          ERROR -8172: Peer's certificate issuer has been marked as not trusted by the user.
            E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 2 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
        Error in function PR_Write: -8172
         - Peer's certificate issuer has been marked as not trusted by the user.

This also happens with my personal mail server (crypt.ethx.net) that
works fine at home. This is looking more and more like a bug in
evolution rather than NSS, except that if I downgrade to NSS 3.12.4
everything works again. Anyway, I will perform the same new-user test on
my home machine with both versions of NSS and report back.

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

Message #53 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Wed, 06 Jan 2010 14:22:32 +0000

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.

Given #563324, I guess that upgrading NSS prevents evolution from
verifying certificates entirely.

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

Message #58 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Wed, 6 Jan 2010 17:39:35 +0100

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.

Thanks.

Mike

Message #63 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Wed, 06 Jan 2010 17:06:08 +0000

[Message part 1 (text/plain, inline)]

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.

> Thanks.
> 
> Mike

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

[old-nss (text/plain, attachment)]

[new-nss (text/plain, attachment)]

Message #68 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Wed, 6 Jan 2010 18:10:10 +0100

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 ?

Thanks

Mike

Message #73 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Wed, 06 Jan 2010 17:43:35 +0000

[Message part 1 (text/plain, inline)]

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

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

[new-nss (text/plain, attachment)]

[old-nss (text/plain, attachment)]

Message #78 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Thu, 7 Jan 2010 10:03:56 +0100

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

Message #83 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Fri, 08 Jan 2010 16:51:03 +0000

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@robots.org.uk>

Message #88 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Fri, 8 Jan 2010 18:20:52 +0100

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

Message #95 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Fri, 08 Jan 2010 17:42:47 +0000

On Fri, 2010-01-08 at 18:20 +0100, Mike Hommey wrote:
> > > 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.

Oh--if I create a profile, the certificate list is empty. But if I then
symlink in libnssckbi.so and re-launch evolution, the certificate list
is populated. So I think that modifying evolution to only open
"libnssckbi.so" and then relying on NSS to to find the library will do
the right thing.

> Mike

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

Message #100 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Mon, 11 Jan 2010 15:19:14 +0100

[Message part 1 (text/plain, inline)]

reassign 563253 evolution
tag 563253 + patch
thanks

On Fri, Jan 08, 2010 at 05:42:47PM +0000, Sam Morris wrote:
> On Fri, 2010-01-08 at 18:20 +0100, Mike Hommey wrote:
> > > > 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.
> 
> Oh--if I create a profile, the certificate list is empty. But if I then
> symlink in libnssckbi.so and re-launch evolution, the certificate list
> is populated. So I think that modifying evolution to only open
> "libnssckbi.so" and then relying on NSS to to find the library will do
> the right thing.

I gave some more thought to the issue, and it appears quite pointless to
try to workaround the issue in nss to fix broken configurations, while
evolution will still need a modification for new profiles.

I'm therefore reassigning this bug to evolution, and attaching an
untested patch, that should just do the right thing. Please give it a
try.

Cheers,

Mike

[diff (text/plain, attachment)]

Message #111 received at 563253@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Mike Hommey <mh@glandium.org>

Cc: 563253@bugs.debian.org

Subject: Re: With nss 3.12.5, evolution does not know about _any_ certificate authorities

Date: Tue, 12 Jan 2010 18:57:55 +0000

> I gave some more thought to the issue, and it appears quite pointless to
> try to workaround the issue in nss to fix broken configurations, while
> evolution will still need a modification for new profiles.
> 
> I'm therefore reassigning this bug to evolution, and attaching an
> untested patch, that should just do the right thing. Please give it a
> try.

The patch works for me. Thanks for your help!
> 
> Cheers,
> 
> Mike

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

Message #116 received at 563253-close@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: 563253-close@bugs.debian.org

Subject: Bug#563253: fixed in evolution 2.28.2-2

Date: Tue, 12 Jan 2010 22:17:47 +0000

Source: evolution
Source-Version: 2.28.2-2

We believe that the bug you reported is fixed in the latest version of
evolution, which is due to be installed in the Debian FTP archive:

evolution-common_2.28.2-2_all.deb
  to main/e/evolution/evolution-common_2.28.2-2_all.deb
evolution-dbg_2.28.2-2_amd64.deb
  to main/e/evolution/evolution-dbg_2.28.2-2_amd64.deb
evolution-dev_2.28.2-2_amd64.deb
  to main/e/evolution/evolution-dev_2.28.2-2_amd64.deb
evolution-plugins-experimental_2.28.2-2_amd64.deb
  to main/e/evolution/evolution-plugins-experimental_2.28.2-2_amd64.deb
evolution-plugins_2.28.2-2_amd64.deb
  to main/e/evolution/evolution-plugins_2.28.2-2_amd64.deb
evolution_2.28.2-2.diff.gz
  to main/e/evolution/evolution_2.28.2-2.diff.gz
evolution_2.28.2-2.dsc
  to main/e/evolution/evolution_2.28.2-2.dsc
evolution_2.28.2-2_amd64.deb
  to main/e/evolution/evolution_2.28.2-2_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 563253@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Yves-Alexis Perez <corsac@debian.org> (supplier of updated evolution package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Tue, 12 Jan 2010 21:37:26 +0100
Source: evolution
Binary: evolution evolution-common evolution-dev evolution-dbg evolution-plugins evolution-plugins-experimental
Architecture: source all amd64
Version: 2.28.2-2
Distribution: unstable
Urgency: low
Maintainer: Debian Evolution Maintainers <pkg-evolution-maintainers@lists.alioth.debian.org>
Changed-By: Yves-Alexis Perez <corsac@debian.org>
Description: 
 evolution  - groupware suite with mail client and organizer
 evolution-common - architecture independent files for Evolution
 evolution-dbg - debugging symbols for Evolution
 evolution-dev - development library files for Evolution
 evolution-plugins - standard plugins for Evolution
 evolution-plugins-experimental - experimental plugins for Evolution
Closes: 548510 563034 563253
Changes: 
 evolution (2.28.2-2) unstable; urgency=low
 .
   [ Josselin Mouette ]
   * Drop libgnomeprint build-dependencies.
 .
   [ Yves-Alexis Perez ]
   * debian/po:
     -  Try to really remove spurious spaces in debconf templates and unfuzzy
     translations.                                               closes: #548510
     - add pt_BR.po, thanks Fábio Ferreira.                      closes: #563034
   * debian/patches:
     - 02_let-nss-search-for-nssckbi added, fix nss modules lookup, should fix
       certificate verification in evolution.                    closes: #563253
Checksums-Sha1: 
 8cf2116f4d5a5f1d0ccc91803d592373339a13fa 3684 evolution_2.28.2-2.dsc
 7cb7d94d2ccb19dc6ff10ebf77449303810beb0c 35311 evolution_2.28.2-2.diff.gz
 ed6ed1587da2b6b2bd95906a41e87c4d65e8cc8d 26464164 evolution-common_2.28.2-2_all.deb
 abfb974087adc8895f175f0727f6143571bde6f3 3456122 evolution_2.28.2-2_amd64.deb
 fba2a4e1d285e90848dbd24c38c89dc7640f2b2f 338650 evolution-dev_2.28.2-2_amd64.deb
 88004012fb4045250a40acba90703f1d61fecad9 7976664 evolution-dbg_2.28.2-2_amd64.deb
 83de1e9b233ead59411161991249b3eadc2308e0 218350 evolution-plugins_2.28.2-2_amd64.deb
 3ea83ece191bbc07423752d2facb5193650f771e 187890 evolution-plugins-experimental_2.28.2-2_amd64.deb
Checksums-Sha256: 
 4f0b5f64131385a915ed6f00b412246e0c1e6a419209e2eaff30fcdbe5055842 3684 evolution_2.28.2-2.dsc
 ea0677fde9c9a7b22cd28bf34b38d421c1c0a7dc15d378c9316f2992b636a279 35311 evolution_2.28.2-2.diff.gz
 775bc9f0f56857fb091252ec0afd63b6240010c9d7a8ae1c75254b95bbdbcf73 26464164 evolution-common_2.28.2-2_all.deb
 0bd77e48115e8271457e97f4c0edef857e832c3fcaf73bd659c42a40d9c542fb 3456122 evolution_2.28.2-2_amd64.deb
 2240bdac10848abe71b19641f85c9512f4db1970974681b022397625170f5e87 338650 evolution-dev_2.28.2-2_amd64.deb
 4980c73cf7ce401f3cf927888076d35187d94d895862d135d913d86daa7f8303 7976664 evolution-dbg_2.28.2-2_amd64.deb
 5bb569646fe4d665a74b93cb6261adc27e406f3ec5412e72dc7f5ab7e9b47400 218350 evolution-plugins_2.28.2-2_amd64.deb
 5e1baa9c7c515ce851a5316a3c9bec540f7e8482424ca1001c9b5c919f8a3a7c 187890 evolution-plugins-experimental_2.28.2-2_amd64.deb
Files: 
 3c78dbbf6c725f6b89a8d69ebd72fa6e 3684 gnome optional evolution_2.28.2-2.dsc
 73ad755b46a924a91707914814157b3d 35311 gnome optional evolution_2.28.2-2.diff.gz
 ce83ec24d9159024a334a8cd2b904651 26464164 gnome optional evolution-common_2.28.2-2_all.deb
 9442abfa71d7508d268164e1fd36337d 3456122 gnome optional evolution_2.28.2-2_amd64.deb
 432c8d89c76d4ecbb3c72dc666b9701a 338650 devel optional evolution-dev_2.28.2-2_amd64.deb
 1b134e450ca628e3de9c86d2d1b9b735 7976664 debug extra evolution-dbg_2.28.2-2_amd64.deb
 abb6cfd04b1a351ad70d0362a1929b72 218350 gnome optional evolution-plugins_2.28.2-2_amd64.deb
 3aac9dadd62bcdde44cd2fa07f7d0b54 187890 gnome optional evolution-plugins-experimental_2.28.2-2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJLTO6RAAoJEDBVD3hx7wuoSM0QANlOxSplHrsJKGQ3ZnSah9Sr
PDzlMjYScl7y/3rjIswaqTNKRH4WmdgihK6eEA6yft31KXxFRGpcahW8+sR9GKbW
xuPtQYDwPJZlb8SktklACAEcgpjHweh4W03gvlig+ipBOP+VPUHlf0RKKoBQjrER
222ufrQR+1pNYS92tefztsi/fHoMG2Y7PZNRu9CGx9DhFQ9mF2ZD+fkvgmoJ2fP6
2Achb6s2sy5mal0wwzjlq6SH4Vl6rxuHnv+GKG19m38VA0YuFVnYItEQJaFHk0iC
jIHSSRGeAlMAVU29YAH1Z+FmrZY+bvwNEjl0wvWY8iNNI2ZY9mFGv7LTRpuif8UU
vA8hDwtiinzZrmT7VRNm0JusKZHM924saTO7hgC2sn5d9JPzPKQGrbIXl/t4guCE
fqFZ9lS+nnbOCmYDpmUOzZ8jaY7BgyVmC8VDDkgJGeukjx/qiTLZ5dCYp1IYbmoS
QkPKCp95juorHHM+WVzHcBQDfco63DIvJrW3dOvG8Bln+LAg2FzXSVjBSpKCnwiW
JUUnuM8QIWcf0+Oq8Dr/9X81EQsJsc/mHGH57wKx/120pb2AOPlbZgw53UWa341O
U/Ug/OJTlwldDbkDzGHY/9iJMbgGm+l8BtMIPsaWtdybnILaZgd0aP2gA2uVkw8n
062ifYKPOYWZQcLKjEo0
=pUZX
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.