GNOME Bugzilla – Bug 527193
seahorse-agent crashes, trying to prompt for passphrase, when I attempt to perform "gpg --sign"
Last modified: 2008-04-17 18:49:00 UTC
Steps to reproduce: 1. .xsession/.xinitrc have "ssh-agent dbus-launch --exit-with-session seahorse-agent --execute gnome-session" 2. Run "startx" 3. X loads, bring up a terminal 4. Run "gpg --sign < some_file.txt" 5. GPG expresses that there's an agent error, and asks for the passphrase manually 6. The agent error is because seahorse-agent crashed in mid-protocol Stack trace: (gdb) bt
+ Trace 194755
Other information: Output of crashing session by running seahorse-agent as "seahorse-agent -c -d -A" and setting GPG_AGENT_INFO appropriately in another xterm to test gpg: cokane@erwin:~> seahorse-agent -c -d -A setenv GPG_AGENT_INFO /var/tmp/seahorse-VqwNoP/S.gpg-agent:14755:1 /usr/local/share/themes/Beastie/gtk-2.0/gtkrc:56: Clearlooks configuration option "menuitemstyle" is not supported and will be ignored. /usr/local/share/themes/Beastie/gtk-2.0/gtkrc:57: Clearlooks configuration option "listviewitemstyle" is not supported and will be ignored. /usr/local/share/themes/Beastie/gtk-2.0/gtkrc:58: Clearlooks configuration option "progressbarstyle" is not supported and will be ignored. [multi-operation 0x006EA5E0] start [multi-operation 0x006EA5E0] adding part: 0x006F0D30 [multi-operation 0x006EA5E0] single progress: Loaded 200 keys 0.000000 [multi-operation 0x006EA5E0] adding part: 0x007AD5C0 [multi-operation 0x006EA5E0] part complete (2): 0x007AD5C0/(null) progres is: 1.000000 progres is: 0.000000 [multi-operation 0x006EA5E0] multi progress: Loaded 200 keys 0.500000 [multi-operation 0x006EA4A0] start [multi-operation 0x006EA4A0] adding part: 0x006EA5E0 [multi-operation 0x006EA4A0] single progress: Loaded 200 keys 0.500000 [multi-operation 0x006EA4A0] adding part: 0x007D4C00 [multi-operation 0x006EA4A0] part complete (2): 0x007D4C00/(null) progres is: 1.000000 progres is: 0.500000 [multi-operation 0x006EA4A0] multi progress: Loaded 200 keys 0.750000 progres is: 1.000000 progres is: 1.000000 [multi-operation 0x006EA5E0] multi progress: (null) 1.000000 progres is: 1.000000 progres is: 1.000000 [multi-operation 0x006EA4A0] multi progress: (null) 1.000000 [multi-operation 0x006EA5E0] part complete (2): 0x006F0D30/(null) [multi-operation 0x006EA5E0] complete progres is: 1.000000 progres is: 1.000000 [multi-operation 0x006EA4A0] multi progress: (null) 1.000000 [multi-operation 0x006EA4A0] part complete (2): 0x006EA5E0/(null) [multi-operation 0x006EA4A0] complete [agent-io] send line: OK your orders please [agent-io] got line: OPTION display=:0.0 [agent-io] send line: OK [agent-io] got line: OPTION ttyname=/dev/tty [agent-io] send line: OK [agent-io] got line: OPTION ttytype=xterm [agent-io] send line: OK [agent-io] got line: OPTION lc-ctype=en_US.UTF-8 [agent-io] send line: OK [agent-io] got line: OPTION lc-messages=en_US.UTF-8 [agent-io] send line: OK [agent-io] got line: GET_PASSPHRASE FC09F3264318E714DE456CB070C4B141C5DAB797 X X You+need+a+passphrase+to+unlock+the+secret+key+for+user:%0 A"Coleman+Kane+(Personal+PGP+Key)+<cokane@cokane.org>"%0A1024-bit+DSA+key,+ID+C5DAB797,+created+2007-07-22%0A ** (seahorse-agent:14755): WARNING **: couldn't search keyring: (code 9) (process:14755): GLib-ERROR (recursed) **: gmem.c:136: failed to allocate 40 bytes aborting... (process:14755): GLib-ERROR (recursed) **: gmem.c:136: failed to allocate 108 bytes aborting... Multiple segmentation faults occurred; can't display error dialog
I am running this on FreeBSD 8.0-CURRENT, amd64.
The problem is the fact that FreeBSD's mlock() requires setuid privileges, and thus seahorse cannot allocate secure memory. The standard malloc functions are overridden in libseahorse/seahorse-secure-memory.c. Because they fail to allocate secure memory, everything fails, and the agent aborts. If you comment out the guts of seahorse_secure_memory_init(), things should work. That said, it should not be fatal that the gnome-keyring secure memory functions don't work. That should just result in a warning, and a fallback to insecure memory. Perhaps the bug needs to be moved to gnome-keyring.
Created attachment 109016 [details] [review] OBSOLETE: Patch to turn WITH_SECURE_MEM(EXP) into a noop I dropped the above patch into security/seahorse/files/ on my system and rebuilt. This allows me to use seahorse now for my GPG keying (and Evolution works fine now). However, it results in just using a normal malloc for the memory allocation. Personally, I don't mind this on this machine as there are no other users and I can overwrite swap if I really want to. Anyhow, a seahorse-agent that uses swappable memory is more useful to me than a seahorse-agent that crashes upon use.
Created attachment 109055 [details] [review] Add a "has secure memory" check function to libseahorse/seahorse-secure-memory.c
Created attachment 109056 [details] [review] Header patch for the check function in the libseahorse/seahorse-secure-memory.h attachment
Created attachment 109057 [details] [review] Patch to the seahorse-agent main function so that it conditionally sets secure-memory malloc overrides, only if the feature exists. Warns user otherwise.
Apply the three recently attached patches, or just place them inside of /usr/ports/security/seahorse/files, and rebuild the seahorse port. These change the behavior of seahorse-agent such that it conditionally performs the g_malloc overrides only in the case where libgnome-keyring does support secure memory. Otherwise, it warns the user that insecure memory will be used and proceeds to run without crashing.
Comment on attachment 109016 [details] [review] OBSOLETE: Patch to turn WITH_SECURE_MEM(EXP) into a noop The WITH_SECURE_MEM(SXP) patch is obsoleted by the others, but apparently I can't just go in and set this manually after the fact, I have to do it when I upload a patch.
After some discussion w/ marcus AT freebsd DOT org, we determined that gnome-keyring is working properly. The seahorse-agent program needs to check that libgnome-keyring's gnome_keyring_memory_try_alloc call will work before it decides to go and re-assign all of the mem-management call-outs. I'm setting the "Product" back to "seahorse" now.
I really think that there should be an "agent" component available as well.
Created attachment 109132 [details] [review] Revised libseahorse/seahorse-secure-memory.c patch I am uploading a new patch to libseahorse/seahorse-secure-memory.c that performs the conditional-g_malloc-remapping inside seahorse_secure_memory_init(), so that it fixes all of the binaries that were broken when gnome_keyring_memory_try_alloc returns a NULL pointer because mlock() can't be used by the current user. It warns the user of these programs that their password entries will be insecure. Earlier I said that this affected seahorse-agent, but it does affect all seahorse apps that use seahorse_secure_memory_init() and the secure mem allocation implementations. So "general" is the appropriate category.
Changing OS to "All", as this situation is confirmed to exist on most BSD's, Solaris, and Linux kernels earlier than 2.6.9.
I changed the wording of the error messages and changed the order of the two functions. Thanks. Committed to trunk and gnome-2-22. 2008-04-17 Adam Schreiber <sadam@clemson.edu> * libseahorse/seahorse-secure-memory.c: Test for secure memory before remapping memory functions. Patch from Coleman Kane. Fixes bug #527193