Seahorse won't generate a key when .gnupg directory owned by root, only gives unhelpful "General error"

I cannot reproduce this on Jaunty.

This is, nevertheless, a dangerous thing to do: if you are logged under your own userid (not root), and you 'gksudo seahorse', you will change the ownership of the ./gnupg/(pub|sec)ring.gpg to root -- which will mean you will lose access to your gpg keyrings.

On the other hand, this message is weird...

I'm glad that you cannot reproduce it on Jaunty.

I first tried to generate a new key without using gksudo and it resulted in the exact same message.

emeriste, please do a 'ls -l ~/.gnupg/*.gpg'. This will will list (among other things) which user and group owns the files.

There should be 3 files, pubring.gpg, secring.gpg, and trustdb.gpg. These 3 files -- in fact, *all* under ~/.gnupg -- should be owned by your userid, your group, not by root, or any other user.

Please comment on what you find.

Thanks.

We are closing this bug report because it lacks the information we need
to investigate the problem, as described in the previous comments.
Please reopen it if you can give us the missing information, and don't
hesitate to submit bug reports in the future. To reopen the bug report
you can click on the current status, under the Status column, and change
the Status back to "New". Thanks again!

I confirm that gpg key generation is broken on Ubuntu 8.10 running on
Linux cesar 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux

I get pretty the same error.

Here's the info you asked:

cesar@cesar:~$ ls -A .gnupg/ -ld
drwx------ 2 cesar cesar 232 2009-03-10 16:13 .gnupg/
cesar@cesar:~$ ls -ld /home/cesar/.gnupg/
drwx------ 2 cesar cesar 232 2009-03-10 16:13 /home/cesar/.gnupg/
cesar@cesar:~$ ls -l /home/cesar/.gnupg/
Total 20
-rw------- 1 cesar cesar 28 2008-10-26 01:07 gpg.conf
-rw------- 1 cesar cesar 2614 2008-12-11 00:58 pubring.gpg
-rw------- 1 cesar cesar 2614 2008-12-11 00:58 pubring.gpg~
-rw------- 1 cesar cesar 600 2009-03-10 16:14 random_seed
-rw------- 1 cesar cesar 0 2008-10-26 02:23 secring.gpg
-rw------- 1 cesar cesar 1200 2008-12-11 00:58 trustdb.gpg

As you can see I'm the only user who has access to these files (as it should be, afaiu).

I ran across the same problem this morning and found the trustdb file was owned by root.

-rw------- 1 root root 1200 2008-11-10 10:24 /home/mike/.gnupg/trustdb.gpg

changing ownership:

1.) Allowed me to add new keys
2.) Made old ones visible that I didn't know were there. (forgotten long ago)

I apologize, I am on Jaunty as well.

I tried this again, this time on a fresh Jaunty install (that had no existing .gnupg directory) and could not reproduce the error.

Sorry, Mike, I did not comment before because I (wrongly) considered you had already seen your issue: at one point in time either you ran seahorse or gpg under sudo or gksudo.

Your issue was somehow the ./gpg files got owned by root. This is different from Ithor.

@Ithor: please:

(1) make sure all files under your ~/.gnupg are still owned by your userid;
(2) run seahorse from the command line;
(3) try to repeat the issue;
(4) post all messages generated here.

Thank you.

setting to Incomplete: waiting on reply.

Get a "<big><b>Couldn't generate PGP key</b></big>

General error" msg as well.
~/.gnupg owned by me.

Command line did this.

jim@Gerrard:~$ seahorse
** Message: init gpgme version 1.1.6

(seahorse:6354): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(seahorse:6354): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(seahorse:6354): GLib-GObject-WARNING **: invalid cast from `GtkCheckButton' to `EggDateTime'

** (seahorse:6354): CRITICAL **: egg_datetime_get_as_time_t: assertion `EGG_IS_DATETIME (edt)' failed
** Message: could not grab keyboard

on Ubuntu 8.10

You also need to uncheck the "never expires" option to reproduce this.

Importance for me is actually _High_

I can confirm this problem, as mentioned in detail by Jimbo (https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/321287/comments/11)

System:
gpg (GnuPG) 1.4.9
2.6.27-14-generic #1 SMP Tue Jun 30 19:57:39 UTC 2009 i686 GNU/Linux

* The error occurs only if you click the button "_Create" (with the mouse). If you press Alt+C or focus this button and press Enter, the key will be generated as normal (with expiration date 1970-01-01).

* Only the command line message
------------
** (seahorse:26768): CRITICAL **: egg_datetime_get_as_time_t: assertion `EGG_IS_DATETIME (edt)' failed
** Message: could not grab keyboard
------------
seems to be interesting, because the other ones appears even if you don't uncheck "Never Expires".

* There's no date-time-field left to the "Never expires"-button as seen here: http://media.ubuntuusers.de/wiki/attachments/34/28/seahorse-new-pgp-key.png

* Surprisingly, after appearence of the error message "<big><b>Couldn't generate PGP key</b></big>", the sorting order first PGP-key, second SSH, has changed in SSH, PGP (at "Generate a new key"-window).

**************************************************
* Another bug maybe connected with this one:
at key properties-window > details: changing the expiration date at a date less or equal the current date will result in the message:
-----------------
<big><b>Couldn't change expiry date</b></big>

General error
----------------

Command line messages, first before closing the error message window
---------------
** (seahorse:29571): CRITICAL **: file seahorse-pgp-key-op.c: line 1024 (edit_expire_transit): should not be reached
---------------
and after closing
---------------
(seahorse:29571): Gtk-CRITICAL **: gtk_window_group_remove_window: assertion `GTK_IS_WINDOW_GROUP (window_group)' failed
---------------

Thanks for reporting, still can't reproduce this on current karmic. Could you give detailed steps or maybe record a screencast on how to reproduce this problem?

I got this error but I was able to resolve it by changing the ownership of pubring.gpg from root to me.

I also have this issue on Ubuntu 9.10 AMD64.

It occurs here each time.

Seahorse -> File -> New -> PGP Key. I fill in everything and keep the default options.
Then I have to wait for several minutes while a popup windows "key generation / primegen" is displayed. Then I get the "General error" message.

I still have the ownership over pubring.gpg, and never used gksudo to launch Seahorse.

What may I do to help investigate this bug ?

Cheers !

OK so, I figured out more or less what was wrong.

The first time I created the PGP Key, I didn't specify a password (I wanted to check what would happen). It instantly displayed "general error". Then, my subsequent tries triggered the issue that is specified above.

When I tried to create the key via the terminal (as it didn't work with seahorse), here is what was displayed at the end of the process :
gpg: fatal: /home/sandra/.gnupg/trustdb.gpg: base de confiance invalide

Actually, some bad data had been stored the first time even though the process had failed.
I had deleted by hand "pubring.gpg" because I had noticed some data had been stored there, but I should have deleted the entire directory as well.

Anyway, there's a bug somewhere. Any idea where I should report it ?

I can confirm this on Lucid 10.04 x64.
Never expires option was checked; tried to generate a PGP key.

Confirm this on Lucid 10.04 i686

Above is requested:

"please do a 'ls -l ~/.gnupg/*.gpg'. This will will list (among other things) which user and group owns the files.

There should be 3 files, pubring.gpg, secring.gpg, and trustdb.gpg. These 3 files -- in fact, *all* under ~/.gnupg -- should be owned by your userid, your group, not by root, or any other user.

Please comment on what you find.

Thanks."

Here is my finding:

$ ls -l ~/.gnupg/*.gpg
ls: cannot access /home/<username>/.gnupg/*.gpg: Permission denied
<username>@<computername>:~$ sudo ls -l ~/.gnupg/*.gpg
ls: cannot access /home/<username>/.gnupg/*.gpg: No such file or directory

My steps were: first I tried to generate a PGP key from the command line but failed and was unable to find the steps to do it properly that way. So I installed Seahorse.

1) Started Seahorse from menu
2) Tried 'Sync and publish keys' but that seemed to stall, so I cancelled it.
3) I press on the 'new' button to generate a new key. I select PGP key and press continue. I fill out the fields for 'real name', 'email address', and 'comment'. I so NOT click on the arrow for advanced options. I click on 'Create'. It asks me for a Passphrase for New PGP Key. I enter my password two times, the same both times. I click OK.

A box pops up with an error message in it:

Couldn't generate PGP key

General error

@nUboon2Age (and, actually, just for the record, since s/he did not subscribe to this bug... fire-and-forget type of thing)

> $ ls -l ~/.gnupg/*.gpg
> ls: cannot access /home/<username>/.gnupg/*.gpg: Permission denied

The above is already good enough to state your userId does not seem to be the owner of the directory ~/.gnupg, or of the files under it. Either one or the other gave you a "Permission denied" error.

You can find out byt running 'ls -la ~ | grep gnupg'.

Update and RESOLUTION:

What it boils down to is that previously I'd run the command line gpg tool with sudo. Like the original gug reporter, my .gnupg directory was therefore owned by root. To fix it I deleted the directory and ran Seahorse again in normal user mode (ie. w/o sudo).

Here's my investigative steps that lead me there:
 even though above I reported that
  ls -l
and even
  sudo ls -l
didn't see the file, when I check it with sudo nautilus (view hidden files) it does see the .gnupg directory and the directory and files are owned by root. Since the date on the files is yesterday I'm guessing that they were created by my command line attempts yesterday and since they are owned by root I'm guessing I did 'sudo' to create a PGP key pair after an attempt to create it without sudo failed with an error. The files are:
 gpg.conf
 pubring.gpg
 pubring.gpg~
 trustdb.gpg

I deleted the entire directory and try again from Seahorse without sudo priviledges.

WORKED!

Suggested Fix:
1) inform the operator that the .gnupg directory is owned by root and therefore cannot be used to generate a key
2) either (preferred) a) give operator option to delete the directory b) authenticate their sudo password, delete the directory and then c) ask if they wish to try again (ie. without having to re-enter the configuration info).
or (at least) b) provide a short explanation that they will need to do the steps above manually.

Note: the op reported that the error dialog box actually showed the html tags. Since this is no longer the case, that aspect of the bug seems to have been fixed.

Hi nUboon2Age,

I see some problems with (2.1-2.3). The most critical point is: if we delete the whole directory (or even some of the .gpg files) we are potentially destroying user data -- gone are your private keys, your trusted database, your list of locally-signed keys, etc. In my case, for example, this would destroy 6 different GPG keys I use.

As such, (2.1 - 2.3) are not an option.

I do agree, though, that a better explanation should be provided. I will look upstream and either open a bug report there, or link an existing one here.

As such, accepting status == Confirmed.

I think the comments by Jimbo and Dominic above are probably a different bug (possibly bug #321287) which then would need to be written up separately.

Note: looking at the gpg documentation, my guess is that http://www.gnupg.org/gph/en/manual.html#AEN26 gives "General error" for several different error conditions and cannot therefor be used to identify exactly what the underlying problem is.

C de-Avillez, yes that is a good point about potentially unintentionally destroying other data. I wonder if Seahorse just changed the permissions to be controlled by userid if that would solve the problem. I think it probably would. The thing is that if you give new to intermediate users with the info but no immediate action they can take to fix it, they could be stuck w/ no knowledge of how to fix the situation, so I favor a fix that Seahorse immediately offers and can carry out in entirety.

New Suggested Fix (taking into account C de-Avillez's input above):
1) inform the operator that the ~/.gnupg/ directory and all the files in it are owned by root and therefore cannot be used to generate a key.

2) either

(my strong preference)
2.1.1) give operator option to change the ownership of the directory and files to be controlled by their userid.
2.1.2) authenticate their sudo password, make the ownership changes.
2.1.3) ask if they wish to try creating the keys again (ie. without having to re-enter the configuration info).

or

(minimally -- I don't prefer this and think its inadequate)
2.2.0 provide a short explanation that they will need to do the steps above manually.

From a user experience view point I think the 2.1.1-3 branch is quite a bit better. The user is well-informed as to what the problem is and has an immediate action they can take to fix the brokeness and to continue on with the creation of their keys. Otherwise they may be stuck in a situation they don't have the knowledge to fix and essentially Seahorse will stop working for them -- again note that in this root ownership condition 'Syncing and Publishing' is broken as well, so applying this fix would solve that problem as well. Also this set of actions could be added to the 'Syncing and Publishing' function as well (if there is not already a bug report written for that bug there probably should be).

Unfortunately, if ~/.gnupg is owned by root, Seahorse will not be able to chown it back:

cerdea@xango2:~$ ls -l test
total 0
cerdea@xango2:~$ chmod 700 test
cerdea@xango2:~$ sudo chown root:root test
[sudo] password for cerdea:
cerdea@xango2:~$ ls -la test
ls: cannot open directory test: Permission denied
cerdea@xango2:~$ chown cerdea:cerdea test
chown: changing ownership of `test': Operation not permitted
cerdea@xango2:~$ ls -l | grep test
drwx------ 2 root root 4096 2010-04-30 17:51 test
cerdea@xango2:~$

In other words: in this case, the only thing any programme can do is warn you.

the workaround is giving permission to your user:

sudo chown; chgrp "user" file (without the "quotation")

you have to do this to all files inside the ~/.gnupg directory
and then you can create your key!

On Ubuntu 12.04, I was having same issue. By changing group and owner of `.gnupg/*` resolved this issue for me:

vishal@vishal:~$ ls -la | grep .gnupg
drwx------ 2 root root 4096 Apr 23 18:12 .gnupg
vishal@vishal:~$ sudo chown -R vishal .gnupg
vishal@vishal:~$ sudo chgrp -R vishal .gnupg
vishal@vishal:~$ ls -la .gnupg
total 32
drwx------ 2 vishal vishal 4096 Apr 23 18:12 .
drwxr-xr-x 135 vishal vishal 4096 Aug 16 09:07 ..
-rw------- 1 vishal vishal 9398 Oct 11 2011 gpg.conf
-rw------- 1 vishal vishal 1637 Apr 23 18:12 pubring.gpg
-rw------- 1 vishal vishal 1637 Apr 23 18:12 pubring.gpg~
-rw------- 1 vishal vishal 0 Oct 11 2011 secring.gpg
-rw------- 1 vishal vishal 1200 Apr 23 18:12 trustdb.gpg

---------------------
Now I can safely create PGP key.

vishaltelangre upper workaround at #31 worked for me (Ubuntu 12.04.2 x86_64)

Confirmed on Ubuntu 14.04 LTS.