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.mur...@mykolab.com > On 31 Dec 2014, at 16:54, Daniel Kahn Gillmor <d...@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
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
