[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-users
Subject:    Re: Key selection
From:       Sandeep Murthy <s.murthy () mykolab ! com>
Date:       2014-12-31 21:09:24
Message-ID: 03B194EF-130A-4E0E-9E05-D9AF1183155F () mykolab ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi

I didn't mean to suggest that `gpg` should do any guessing in this
situation.

Maybe I'm wrong and this is a minor issue, but from
a simple request-response model point of view when
`gpg —edit-key` is invoked by a user with an argument which i
not a specific key ID but an email which is associated with
multiple keys in the keychain then it seems it should certainly
not cause `gpg` to point to any revoked or expired key, as is
happening now (for me anyway).  This is clearly a bug, and
surely there's an easy fix for it - check whether there are
any active (non-expired, non-revoked) keys, if so present the
list to the user to choose, if not print an appropriate message
that would cause the user to either generate a new key for that
email, and edit that key, or do a lookup on another source where
they have stored keys.

This issue is specific to the command line program, not any
GUI based program like Keychain (from MacGPG2 suite), because
there the user can see the keys and know which one to edit.

Sandeep Murthy
s.murthy@mykolab.com



> On 31 Dec 2014, at 16:54, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On 12/27/2014 02:41 PM, Doug Barton wrote:
>> On 12/27/14 9:36 AM, Sandeep Murthy wrote:
>> | I have four keypairs associated with my main email, two of which
>> | are revoked and one expired. But if I try to edit the main key
>> | associated with email by
>> |
>> | $ gpg --edit-key <email>
>> |
>> | then it invokes gpg and points to one of the revoked keys rather
>> | than the active key. I have to explicitly give the short ID of the
>> | active key to edit that key and get its fingerprint.
>> |
>> | Is there a way to change this, or I am doing something wrong?
>> 
>> No, and no. :)
>> 
>> If you have multiple keys that match a pattern (such as your e-mail
>> address) then gpg is going to take its best guess as to which one you
>> mean.
> 
> The short version of the story is that its best guess really isn't very
> good for any existing version of gnupg.
> 
> Its "best guess" is just based on a linear scan of the keyring,
> returning the first certificate with a matching user ID.  The linear
> scan is based on the date that each key was first added to your keyring.
> 
> While this is a disappointing guess, it's also very predictable (within
> one known keyring), and controllable.  One way to control it is to
> export all the old keys to a file, then delete them from your keyring,
> then re-import the file.  Now you'll have all the keys available, but
> the first one in the keyring will be the one you want.  If you have any
> local (non-exportable) signatures, make sure you pass "--export-options
> export-local" when exporting them, and "--import-options import-local"
> when re-importing the file.
> 
> ------
> 
> Ideally, GnuPG would use more sophisticated mechanisms to select the
> "right" key (e.g. by considering calculated validity and expiration and
> revocation information).  And conceivably, it could return an error if
> there were multiple matches.  These are fixes that are much more likely
> to be possible with the keybox format used by the 2.1 series, though, so
> if you want to see that happen, please try to test out GnuPG 2.1.  the
> wider deployment it gets, the better chances we'll have to improve
> matching in general.
> 
> 	--dkg
> 


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.26
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUpGYFAAoJECwOmSKhc9PZbZsP/3FQQXKF5yIi1ViPbmz5QUrf
dlkZ8CqyuXAN+fr5dsdnd8CvB7va63DHO2/lpgPQjJ7W3j/z07cA8BMLnzThRCfs
UHrCGYXx/yAn9VUVQouwCTngyygajsMhOAuo8RVuEceyT6sV0bbvXMXfflMFGZIB
OPgeCH2f40/Iu0wd7/xE74ijdIo+THTpIo8CcIDbjoiYBMuFafm+gn1hFQatb71L
dg+53+5Ph9jAZvyOg+2+CnA1PwQ76nQ1flUX4KW78CX7vZGX6nR30ZD9C84XMHrS
0GbdAEKH55wFbbJ9SsZs72/sRLYm4lTbbfpCrh/74ewQ0zppHFSpZS3jaIUGnP2r
DaCpBCcohAUmDXH1bGxg1sG8G+rXsmHptw8Ge4ZoEeOaYG+eZ8fVX1I9lD2LbGOe
ymMfcFsAS9VpFdZIPY1tsfq3IR2AGpg8E6iculrXNF4wDAEd+X3+X3a6YbwC2fzi
cY/Zoj7PXd2Ilgkkb49AnaILRk/FwXA1euTlMnirZ6IJkIOX996KplYMRSiDN5JC
vuzAD8TD2fkMdI6qlZG9GLwppokKuPX7x0ZezL0jAnvWLqoQo0T2Gxh0cfU+je+l
LWm2S70BJAj5TU8Vdt/ByVY2PJi53qEEkqxsExCdBvAS5CkpBxONGc5DFTZ8Y3bS
UAYOEAQqn3+vxZOo8//T
=nbqG
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


[prev in list] [next in list] [prev in thread] [next in thread]