Created attachment 1741 [details] Output of "gdb claws-mail" Loading any of these plugins pgpcore.so pgpinline.so pgpmime.so via Configuration->Plugins...->Load... causes Claws Mail to freeze. I attached output of gdb. OS: Xubuntu 16.04.2 Installed with: sudo apt-get install claws-mail claws-mail-plugins claws-mail-extra-plugins claws-mail-pgpinline claws-mail-pgpmime claws-mail-fancy-plugin claws-mail-smime-plugin claws-mail-dbg
What happens when Claws Mail is frozen? Is one (or perhaps more) CPU core at 100%? Can you please, instead of "externally killing" the process, let it run, hit CTRL+c in the console where gdb is running, and get a backtrace ('thread apply all bt full' command)?
Created attachment 1742 [details] gdb backtrace Output of: gdb claws-mail run --debug thread apply all bt full
CPUs are idle during Claws Mail is frozen. Memory consumption does not change and is low.
I am stumped. The freeze obviously happens while Claws Mail is trying to figure out whether you have some secret keys in your keyring - both PGP and S/MIME - but I have no idea why it would just stop. Do these commands finish OK and do they list something out of the ordinary? gpg --list-secret-keys gpgsm --list-secret-keys
It could also be related to some malfunctioning gpg agent. To me it looks as the problem I once had where the agent failed to call the pineentry program and therefore communicated with stdout. If I recall I wrote the proper solution on this bug tracker somewhere.
I ran both commands: gpg --list-secret-keys Lists the key I imported the other day. gpgsm --list-secret-keys No output at all. I deleted the key and tried again to load the plugins. Same behavior as far as I understand. See attachment gdb_backtrace_no_keys. I created another key and tried again, same result. See attachment gdb_backtrace_new_key.
Created attachment 1743 [details] backtrace after deleting existing keys
Created attachment 1744 [details] backtrace after creating new key
What output does the following give: dpkg --get-selections |grep pinentry env |grep -i tty
:~$ dpkg --get-selections |grep pinentry pinentry-gnome3 install pinentry-gtk2 install :~$ env |grep -i tty :~$ (not output for env |grep -i tty)
Try adding this to ~/.bashrc # Set GPG TTY export GPG_TTY=/dev/pts/1 Sometimes below is also necessary but try above first: #$(tty) # Refresh gpg-agent tty in case user switches into an X session gpg-connect-agent updatestartuptty /bye >/dev/null
Created attachment 1745 [details] Output of gdb claws-mail after modifying .bashrc Added export GPG_TTY=/dev/pts/1 to .bashrc. gdb claws-mail run --debug Loading plugins worked as expected.
After adding export GPG_TTY=/dev/pts/1 to .bashrc, the plugin loaded successfully. Thanks! Anything else I can do to help fix/avoid this for others?
It's a Xubuntu 16.04.2 bug, gpg-agent not getting set up correctly. You can report it to them.
Will do, thanks again.
(In reply to comment #13) > After adding export GPG_TTY=/dev/pts/1 to .bashrc, the plugin loaded > successfully. > Thanks! > > Anything else I can do to help fix/avoid this for others? What if your TTY is different next time you log in? I don't think it always has to be /dev/pts/1.
(In reply to comment #16) > (In reply to comment #13) > > After adding export GPG_TTY=/dev/pts/1 to .bashrc, the plugin loaded > > successfully. > > Thanks! > > > > Anything else I can do to help fix/avoid this for others? > > What if your TTY is different next time you log in? I don't think it always > has to be /dev/pts/1. Yes, what you want is this: export GPG_TTY=`tty` Re: https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
I have done some testing. It seems to be of no importance what value the GPG_TTY environment variable has as long as it is set. Maybe of importance for the curses based pinentry but seems irrelevant to the gtk or gnome based pinentry so it could be a bug in gpg-agent?