gnupg chooses an outdated key
Open, WishlistPublic


usure if this is a defect or a nice-to-have:

I created today a new key b/c the other will expires soon. Now I do have 2 keys:

tfoerste@n22 ~ $ gpg --list-keys
gpg: enabled debug flags: memstat trust extprog assuan

pub 1024D/7DB69DA3 2004-08-14 [expires: 2013-12-31]
uid Toralf Förster <>
sub 1024g/160E98C0 2004-08-14


pub 3072D/0076E94E 2013-12-06 [expires: 2023-12-04]
uid Toralf Förster (my 2nd key) <>
sub 4096g/36F8BD16 2013-12-06 [expires: 2023-12-04]

When I use git ( to sign a tag then always the odder 1024 bit key is
used if I do not force git to use the newer key. FWIW I already set the newer
key as default but it doesn't help.


toralf set Version to 2.0.22.Dec 8 2013, 8:43 PM
toralf added projects: gnupg, Bug Report.
toralf added a subscriber: toralf.
toralf added a comment.Dec 8 2013, 9:13 PM

FWIW here's the trace (I pressed Ctrl-C when the passphrase was asked for)

tfoerste@n22 ~/workspace $ git tag -s 'test' -m ''
trace: built-in: git 'tag' '-s' 'test' '-m' ''
trace: run_command: 'gpg' '-bsau' 'Toralf Förster <>'
gpg: enabled debug flags: memstat trust extprog assuan

You need a passphrase to unlock the secret key for
user: "Toralf Förster <>"
1024-bit DSA key, ID 7DB69DA3, created 2004-08-14

gpg: DBG: connection to agent established
gpg: cancelled by user
gpg: skipped "Toralf Förster <>": Operation cancelled
gpg: signing failed: Operation cancelled
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

outmix=0 getlvl1=0/0 getlvl2=0/0

secmem usage: 0/32768 bytes in 0 blocks
error: gpg failed to sign the data
error: unable to sign the tag

werner added a subscriber: werner.

If no key has been specified, gpg uses the first key it finds.
This is not a bug. It might be nicer if gpg would use a heuristic to select a
newer key but that is not the case and quite some work to implement properly.
Thus better specifiy your key in the gpg.conf.

werner lowered the priority of this task from Normal to Wishlist.
toralf added a comment.Dec 9 2013, 8:01 PM

yep - rather an enhancement request then a bug.

OTOH even before the Snowden-era it would be always better to implemented a
strategy to choose the "best" key (in my case the older has 1024 bit - the newer
has 4096).

Retire you old key. There is a "disable" command in "gpg --edit-key".

Werner - taht is the problem - I already tried that (and other hints too) - it
is IMO a lack of a good feature in gpg.