After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 626066 - “trust” properties on certificate authority reset at evolution startup or shutdown
“trust” properties on certificate authority reset at evolution startup or shu...
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
2.30.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks: 629918
 
 
Reported: 2010-08-04 22:08 UTC by Yves-Alexis Perez
Modified: 2010-09-29 10:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log in to slot before initialising certificate GUI (766 bytes, patch)
2010-09-12 14:48 UTC, David Woodhouse
committed Details | Review
login on demand (4.47 KB, patch)
2010-09-13 14:46 UTC, David Woodhouse
none Details | Review
updated patch (4.46 KB, patch)
2010-09-13 14:56 UTC, David Woodhouse
none Details | Review
outstanding patch for 2.32 (2.10 KB, patch)
2010-09-17 14:18 UTC, David Woodhouse
committed Details | Review

Description Yves-Alexis Perez 2010-08-04 22:08:53 UTC
Hey,

I'm reporting against eds because iirc NSS stuff is there but feel free to reassign to evolution in case I was wrong.

I'm trying to add my own CA certificate to evolution, and I wanted to do it cleanly, so I moved .evolution/cert8.db and .evolution/key3.db which I had from the old times (and where my CA was correctly imported), run evolution and went to the certificates properties. There I imported my certificate under the “Authorities” tab, and checked the three “trust” checkboxes. Connecting to my imap server worked fine.

Then, quiting evolution and re-running it, connection to my imap server failed, because of a “BAD Signature”. Going to the authorities certificates, I can see that my cert is there, but the three checkboxes are gone, somehow they are reset.

If you need more info, please ask.
Comment 1 Yves-Alexis Perez 2010-08-12 14:25:02 UTC
Any idea on this, it's rather important, since new evolution installs won't be able to use autorities whose certificates are not included in NSS.
Comment 2 Milan Crha 2010-09-09 11:27:03 UTC
Confirming, I see this too, with actual master of evolution and evolution-data-server and nss 3.12.4. Though I believe the nss shouldn't play a role here, it's rather the evolution forgot to save changes in the trust preferences for an authority.
Comment 3 Milan Crha 2010-09-09 13:01:50 UTC
Hmm, there doesn't seem to be any save or commit function for a certdb in nss, on the first look.
Comment 4 Milan Crha 2010-09-09 17:09:46 UTC
So, reverting all related between today and fix for the bug #585301 in eds and evo makes this work again. So some change in between broke this.
Comment 5 Milan Crha 2010-09-09 17:43:01 UTC
Hrm, I got out of idea here. I tried to not use NSS_InitWithMerge when the local secmod.db wouldn't exist, as I thought it's overwriting this on the merge process, but no luck, it behaves same wrong when using
> status = NSS_InitReadWrite (nss_sql_configdir);
Just for a record:
   nss_sql_configdir:'sql:/home/mcrha/.pki/nssdb'
   nss_configdir:'/home/mcrha/.local/share/evolution'
and the call for sql init succeeded.
Comment 6 David Woodhouse 2010-09-09 21:39:06 UTC
In each case, please indicate which version of NSS you have installed, and whether the 'shared system database' is enabled. There have been a lot of NSS bugs in this area.
Comment 7 Milan Crha 2010-09-10 05:59:02 UTC
(In reply to comment #6)
> In each case, please indicate which version of NSS you have installed, and
> whether the 'shared system database' is enabled. There have been a lot of NSS
> bugs in this area.

Please see comment #2. Tested also with nss 3.12.6-12, doesn't work either. Wouldn't it be better to not depend on an unfinished project in a stable version? I do understand this move in a development version, but with stable version of evolution? I know it's too late, I'm only wondering.
Comment 8 David Woodhouse 2010-09-10 10:00:36 UTC
With evo HEAD, nss-3.12.6-12.fc13.x86_64, shared system db enabled (first line of /etc/pki/nssdb/pkcs11.txt is 'library=libnsssysinit.so'.

My IMAP server has a cert signed by CAcert. I removed the CAcert CA from the system database, connected with Evo and it complained about the cert. I hit 'cancel', went into the preferences and imported the CAcert CAs. Reconnected and it was fine.

Quit evolution, restarted it. It connected to the IMAP server happily, as it should. Went into the preferences and checked, and the CACert CAs both had all three boxes checked still.

(Meanwhile, 'certutil -d sql:/home/dwmw2/.pki/nssdb -L' seems to show that there's no trust, but I think that's a certutil bug:
CAcert Class 3 Root - Root CA                                ,,   
CA Cert Signing Authority - Root CA                          ,,   
)
Comment 9 David Woodhouse 2010-09-10 10:25:06 UTC
I quit Evolution, turned the shared db *off*, and then when I restarted Evolution I found that the trust bits were cleared on the CAcert CAs, which matches what's described above.

I removed the CAcert CAs and re-added them (in evo), and the same thing happened.

Then I removed them again, and added them on the command line with certutil. Now they *do* show up with the trust bits set:
(NULL)                                                       CT,C,C
support@cacert.org                                           CT,C,C

... and everything worked in Evolution.

Then I removed them *again* and added them from Evolution again, and now they're *still* working correctly.
Comment 10 Yves-Alexis Perez 2010-09-10 10:29:47 UTC
Did you check that there was no .evolution/{cert8,key3}.db ?

It seems that evolution uses them first here, thought it might be config related:

cat .pki/nssdb/pkcs11.txt
library=
name=NSS Internal PKCS #11 Module
parameters=configdir='sql:/home/corsac/.pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags= updatedir='/home/corsac/.evolution' updateCertPrefix='' updateKeyPrefix='' updateid='/home/corsac/.evolution' updateTokenDescription='Evolution S/MIME' 
NSS=Flags=internal,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512] askpw=any timeout=30})

library=libnssckbi.so
name=Mozilla Root Certs
NSS=trustOrder=100
Comment 11 David Woodhouse 2010-09-10 11:02:36 UTC
As far as I can tell, things are working fine as long as you use certutil (or firefox or nss-gui or anything else) to import and manage certificates. Please shout loudly if you believe that not to be the case.

I'll look at the issues which our GUI certificate manager has with import (sometimes giving wrong trust), modification of trust (doing nothing), and deletion (doing nothing). And try to make sure it's fixed by Monday...
Comment 12 David Woodhouse 2010-09-12 13:21:19 UTC
I think this is only happening when you have a password on your certificate store. It's not logging in to the slot correctly.
Comment 13 David Woodhouse 2010-09-12 14:48:53 UTC
Created attachment 170084 [details] [review]
log in to slot before initialising certificate GUI

I think this should fix it.
Comment 14 David Woodhouse 2010-09-12 14:57:30 UTC
I filed bug 629432 and bug 629433 for other, probably unrelated bugs in the certificate manager GUI. Note that the latter may cause confusion here.
Comment 15 David Woodhouse 2010-09-12 17:47:44 UTC
To ssh://dwmw2@git.gnome.org/git/evolution
   86e9076..96f4d86  gnome-2-30 -> gnome-2-30
   a6e9aca..fab32c9  master -> master
Comment 16 Milan Crha 2010-09-13 13:38:26 UTC
OK, it "fixed" the issue for me, but in a very horrible way. The first time I open Edit->Preferences, then instead of preferences window I'm asked for my password for the certificate store. When I provide it it works, but when I do not, then it doesn't work (it ~~ changing trust model on an authority certificate).

Though what I hate on this is a fact that I'm going to deal with my account preferences, not with my certificates, thus the password question is quite annoying and useless for most of the times.
Comment 17 David Woodhouse 2010-09-13 14:46:36 UTC
Created attachment 170159 [details] [review]
login on demand

Here's an alternative -- we find the places which may fail with SEC_ERROR_TOKEN_NOT_LOGGED_IN and we individually patch them to attempt to login and then retry the operation (except for import, which only needs to set the trust bits; retrying the import will fail because the certificate *does* get imported the first time; ick).

I don't know if this has yet caught *all* of the cases we'd need to catch; that and the horridness on import are why I went for the simple approach in my original patch.
Comment 18 David Woodhouse 2010-09-13 14:56:33 UTC
Created attachment 170161 [details] [review]
updated patch

New patch: if the CERT_AddTempCertToPerm() call fails, we can't just call it again -- the cert *has* been added, just with the wrong permissions. To recover we need to call CERT_ChangeCertTrust() instead. Ewww.
Comment 19 David Woodhouse 2010-09-13 14:58:50 UTC
https://bugzilla.mozilla.org/show_bug.cgi?id=595861
Comment 21 David Woodhouse 2010-09-13 20:06:30 UTC
To ssh://dwmw2@git.gnome.org/git/evolution
   11cebc8..12415fd  gnome-2-30 -> gnome-2-30
   6ed1e54..c33a84d  gnome-2-32 -> gnome-2-32
   515ad2e..75d1c75  master -> master

I still think the fact that we have to call CERT_ChangeCertTrust() after a failed call to CERT_AddTempCertToPerm() is an NSS bug -- it ought to fail *completely* and we ought to have to call CERT_AddTempCertToPerm() again, surely.

Once NSS is fixed, we may have to try both -- after authenticating, if CERT_ChangeCertTrust() fails then try CERT_AddTempCertToPerm() again, or something like that?
Comment 22 David Woodhouse 2010-09-13 21:42:06 UTC
See https://bugzilla.mozilla.org/show_bug.cgi?id=595861#c4 -- I think we may want to do something like that so we cope with future, fixed versions of NSS. Would like confirmation from Nelson (or someone else clueful about NSS) before we do it though.
Comment 23 David Woodhouse 2010-09-14 21:51:05 UTC
My suggested workaround has now been confirmed as the sane approach, so I've commited it:

To ssh://dwmw2@git.gnome.org/git/evolution
   c7f5d54..47d2599  master -> master

How do I get permission to push the same change to 2.32?
Comment 24 Milan Crha 2010-09-15 06:36:00 UTC
(In reply to comment #23)
> How do I get permission to push the same change to 2.32?

Only after hard code freeze, which ends when 2.32.0 is released. Or you can ask release team for an approval and commit earlier, if they allow.

What is the status of that updated patch in attachments, isn't it committed?
Comment 25 David Woodhouse 2010-09-15 08:40:26 UTC
The cleaned-up version of the patch in comment 18 has been committed (looks like what's in comment 20), which went into 2.32 before the code freeze.

So what's in 2.32 is working with all current versions of NSS but if they *fix* the bug I've reported, then it might stop working. Hence the incremental patch in 47d2599 that I'd like to commit to 2.32 too.
Comment 26 David Woodhouse 2010-09-17 14:18:35 UTC
Created attachment 170486 [details] [review]
outstanding patch for 2.32
Comment 27 David Woodhouse 2010-09-17 14:18:56 UTC
Review of attachment 170486 [details] [review]:

.
Comment 28 Milan Crha 2010-09-29 10:08:59 UTC
Created commit 58a1d6a in evo gnome-2-32 (2.32.1+)