GNOME Bugzilla – Bug 625480
XDG migration - camel certificates
Last modified: 2013-09-13 01:05:12 UTC
Camel certificates doesn't work, I was asked to accept my IMAP server certificate again
Looks like some of the certificate databases have absolute file paths referencing ~/.evolution. I see this in cert9.db, pkcs11.txt and secmod.db, but I'm not even which of these files are still used after David's recent NSS work. Simply moving these files may invalidate the certificates. I don't know if that can be fixed.
Aha, ok, then feel free to won't fix this. Absolute paths in .db files is something pretty hard to fix, I agree.
I've asked David to comment on this before I close it, so just to clarify the problem: We recently moved certificate related files from ~/.evolution to ~/.local/share/evolution. This appears to have broken previously accepted certificates, presumably because the old file path is encoded into the certificate database or the certificates themselves. Is there any resonably easy way to repair this, or will users have to accept new certificates?
hm, this isn't an expected failure -- we should be merging the old dbm database into the new sql database when we first start up the new evolution. After the conversion, *none* of the files in ~/.evolution are relevant -- only the files in ~/.pki/nssdb/ and possibly in /etc/pki/nssdb. Are the certs in your user database? certutil -d sql:$HOME/.pki/nssdb -L Is the system database enabled on your system? sudo setup-nsssysinit.sh off Does it work now? sudo setup-nsssysinit.sh on Does it stop working now?
Assuming the answers were 'yes', 'yes/how_do_I_tell?', 'yes', and 'no'... Install the fixed NSS packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=2255612 With the system database still enabled... does it work now?
Well, my pretty ancient F12 doesn't worth the trouble (and I'm pretty low on disk space these days anyway), thus feel free to close it. I hoped we can make this migration transparent, but as Matt found the paths are inside db files, then not much one can do. Just close this. :)
I'd be happier if we confirmed that it was *only* the Fedora NSS bug causing this -- would be nice if we could confirm that it works nicely under F-13 with the new NSS packages (and perhaps if the fixed NSS packages could actually get shipped as an update). If Fedora isn't going to ship a fixed NSS, we need not to enable the system DB support by default. I've tested this on my own systems, but that's a relatively limited set and I've been screwing with NSS a lot there. More testing would be welcome.
I have also done some testing with but is also limited. We plan to include an NSS fix for F-13. It may be a few days. The Fedora transition to git has come with some hickups. In the meantime I hope people can test against the Rawhide build available at http://koji.fedoraproject.org/koji/buildinfo?buildID=187404
nss-3.12.6-9.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13 Please retest.
OK, so I have installed nss-3.12.6-12.fc13. a) I removed my ~/.evolution b) run fedora's evolution, asked to accept certificate, so far so good c) close evolution, remove ~/.local/share/evolution and run the master evo d) I see migration code, ending with copying camel-cert.db, where I suppose is stored this information. I'm asked to accept the certificate again. Note I didn't do anything special with nss setup, I only played with evolution version being run. The new camel-cert.db, in ~/.local/... is byte-same as the old one. Anyway, I'm closing this.