After updating my system I find that I can no longer see my certificates in Seamonkey.
Even worse, I cannot import certificates from a file backup. I get a pop-up window titled "Change Master Password". So I enter a password, and again for verification. The quality meter indicates a certain quality level. Then I click the OK button. Nothing happens. Clicking repeatedly does not help. Clicking Cancel causes the pop-up to disappear, and I am back at the point where I have no certificates.
The certificate is fine, I have verified that I can import it into Firefox on Windows.
My `emerge --info' is:
Portage 220.127.116.11 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-gentoo-r4 i686)
System uname: Linux-2.6.26-gentoo-r4-i686-Pentium_III_-Coppermine-with-glibc2.0
Timestamp of tree: Wed, 31 Dec 2008 16:05:01 +0000
dev-java/java-config: 1.3.7-r1, 2.1.6-r1
sys-devel/autoconf: 2.13, 2.61-r2
sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2
CFLAGS="-pipe -O2 -march=pentium3"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-pipe -O2 -march=pentium3"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirror.qubenet.net/mirror/gentoo/ http://mirror.fslutd.org/linux/distributions/gentoo/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="X acl acpi alsa apache2 asf avahi berkdb bluetooth branding bzip2 cairo cdr cli cpudetection cracklib crypt cups dbus divx dri dvd dvdr dvdread eds emacs emboss encode esd evo fam firefox fortran gd gdbm gif glibc-omitfp glut gpm gstreamer gtk hal i8x0 iconv isdnlog java jpeg kde libnotify logrotate mad mdnsresponder-compat midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcap pcre pdf perl plotutils png ppds pppd python qt-static qt3 qt3support qt4 quicktime readline realmedia reflection sbcl sdl session snmp spell spl ssl startup-notification svg svga sysfs tcltk tcpd tiff truetype unicode usb vorbis win32codecs wmp wxwindows x86 xml xorg xulrunner xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sv en" USERLAND="GNU" VIDEO_CARDS="intel"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
In case you updated dev-libs/nspr or dev-libs/nss recently, try to re-emerge seamonkey or run revdep-rebuild.
I had a similar problem with seamonkey after update of dev-libs/nspr where seamonkey refused to access https websites being unable to verify the certificates provided by such sites.
I had those symptoms too. A revdep-rebuild caused seamonkey to be rebuilt. That led me up to the current state where my old certificates are lost and new ones cannot be added.
Does certificate handling work for you?
My versions of nss and nspr are:
I found a workaround, like this: Download the Seamonkey binary distribution for Linux from the Seamonkey website. Do some certificate operations. Then switch back to Gentoo-built-from-source Seamonkey. Everything works.
The funny thing is that before installing binary Seamonkey I moved my ~/.mozilla directory to a backup location. The binary Seamonkey caused another ~/.mozilla directory to be created. Then, as soon as I restored my original ~/.mozilla the problems were gone--I could again see my old "lost" certificates.
It seems as if this bug may be hard to reproduce. I would not know how to get back to a state where the bug can again be seen.
Can it be the case that using Seamonkey certificate handling updates some other directory besides ~/.mozilla?
I just discovered that I am again in a situation where certificate handling is broken.
My machine has two installations of Seamonkey. There is www-client/seamonkey-1.1.14, built from source the Gentoo way.
There is also Seamonkey 1.1.14 installed as binary from the official website.
Both installations share some resources. For example, I see the same set of bookmarks regardless of which browser I start.
However, the binary Seamonkey sees my certificates and I can do Internet bank transactions. The Gentoo-built Seamonkey tells me I have no certificates. When I open the bank URL I am told to download a certificate before proceeding.
So, I have a system where I can do some digging for the cause of the fault. I won't do any upgrades or other changes for some time. If anyone can tell me where to look I'll be happy to help.
I have done a Gentoo install from scratch on a different machine. I emerged seamonkey-1.1.16 and there are no problems with the certificate handling, at least not yet.
The problem that I reported may be difficult to reproduce I guess.
I still have the old machine around; if anyone has ideas on how to investigate it please write a comment here. It is always nicer to understand why there was a problem rather than to reinstall and hope for the best :-)
Can you reproduce the problem with seamonkey-2?
I'm afraid not. My Internet bank has switched from certificates to "BankID" (http://www.bankid.com/en/What-is-BankID/) with its own load of problems. Look here for awkward details: http://unix.se/BankID_Skandiabanken_Ubuntu_steg-f%F6r-steg-beskrivning
So, instead of Seamonkey I now use kvm to start a virtualized Ubuntu, in which I run firefox, with "BankID" installed.
Hmm, sounds quite... ehm... awkward to do for online banking...
nevertheless I gonna mark this bug as NEEDINFO then. Maybe someone else can provide updated information which requires this bug to be reopened again.
Awkward indeed .. I agree completely with the guy who wrote this, http://daniel.haxx.se/blog/2009/11/14/the-swedish-bankid-curse-and-debian