After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331873 - Seahorse always picks first added private key to sign keys listed in main window
Seahorse always picks first added private key to sign keys listed in main window
Status: RESOLVED FIXED
Product: seahorse
Classification: Applications
Component: general
0.8.x
Other All
: Normal normal
: 1.0.0
Assigned To: Seahorse Maintainer
Seahorse Maintainer
Depends on:
Blocks:
 
 
Reported: 2006-02-20 08:55 UTC by Daniel Rodriguez Garcia
Modified: 2006-03-13 01:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
UI for selecting signing key (19.16 KB, patch)
2006-02-25 23:12 UTC, Stef Walter
none Details | Review

Description Daniel Rodriguez Garcia 2006-02-20 08:55:31 UTC
Please describe the problem:
Seahorse never shows the private key selection dialog when you are trying to
sign a key listed in seahorse main window.

Although in preferences, the default encryption key option is set to "None.
Prompt for a key.", it always uses the first added private key in your keyring,
and never shows the key selection dialog.

And even worse: if you choose any private key as a default one, it keeps using
the first added private key.

This is in contrast with the case when you are signing a document (e.g. in
nautilus): seahorse does - correctly - shows a key selection dialog in this case.

Steps to reproduce:
I have done the following test:

0. I backup my private keyring (secring.gpg in ~/.gnupg/)
1. Open seahorse from console (I have 2 personal keypairs created):
   Daniel 1 keypair (created first)
   Daniel 2 keypair (created after Daniel 1)
   Daniel 3 keypair (created after Daniel 2)
2. Import a (randomly choosed) public key from a keyserver --> correct
3. The imported public key shows in main window --> correct
4. Right click+sign option or Sign button on that key: the signing confirmation
   box for that key (signing all uids) appears --> correct
5. Accept all, leave default settings, confirm signing action --> correct

6. Seahorse shows the passphrase dialog for Daniel 1 ===> INCORRECT 
   I cancel signing the key

8. I delete Daniel 1, it gets deleted from main window --> correct
9. I close seahorse --> correct
10. I start seahorse from console --> correct
11. Repeat steps 4 and 5 for the same public key --> correct

12. Seahorse shows the passphrase dialog for Daniel 2 ===> INCORRECT 
   I cancel signing the key

13. I close seahorse --> correct 
14. I start seahorse from console --> correct
15. I import my saved private keyring into seahorse --> correct
    Now my Daniel 1 key appears again
16. I change the validity (and trust) for my imported key to ultimate --> correct
17. Repeat steps 4 and 5 for the same public key --> correct

18. Seahorse shows the passphrase dialog for Daniel 2 ===> INCORRECT 
   I cancel signing the key


Actual results:
Thus, seahorse always pick the first added private key when trying to sign
public keys in your keyring (seahorse's main window).


Expected results:
Seahorse should always show the key selection dialog / show passphrase dialog
for default key, in order to be consistent with preferences.


Does this happen every time?
This happens always.

Other information:
Comment 1 Stef Walter 2006-02-25 23:12:54 UTC
Created attachment 60133 [details] [review]
UI for selecting signing key

Here are the UI enhancements for selecting a signing key. IMO, this should always be obvious and present. The default key is selected if there is one.
Comment 2 Stef Walter 2006-02-25 23:15:11 UTC
Thanks for noticing this. 

I was well on my way to fixing this today, but ran into a brick wall. GPGME doesn't support selecting the signing key for a key signature. Which really sucks. If there was a way to pass arbitrary arguments to gpg through GPGME it would work nicely, but no, one of GPGME's stated objectives it provide a backend agnostic interface :(

GPGME is getting in our way more and more. I have half a mind to roll our own interface to GPG like everyone else has done.
Comment 3 Adam Schreiber 2006-02-25 23:49:39 UTC
I'd hate to abandon GPGME, but there appear to be several gpg features we can't implement with it.  KGPG for example interfaces with the command line directly.  I'm not sure that we could continue to be as os independent if we went this route.
Comment 4 Stef Walter 2006-03-13 01:12:01 UTC
Figured out a way to fix this. Was pretty simple, duh. Committed to stable branch. 

I'm not putting in the UI enhancements, this signing interface needs a major rework, and it's one of the things I'm looking into for 0.9.1.