gnupg chooses an outdated key
Open, WishlistPublic
Actions

Assigned To

None

Authored By

	toralf
	Dec 8 2013, 8:43 PM

Description

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
/home/tfoerste/.gnupg/pubring.gpg

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

and

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

When I use git (1.8.3.2-r1) 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.

Details

Version: 2.0.22

Event Timeline

toralf set Version to 2.0.22.Dec 8 2013, 8:43 PM

toralf added projects: gnupg, Bug Report.

toralf added a subscriber: toralf.

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 <toralf.foerster@gmx.de>'
gpg: enabled debug flags: memstat trust extprog assuan

You need a passphrase to unlock the secret key for
user: "Toralf Förster <toralf.foerster@gmx.de>"
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 <toralf.foerster@gmx.de>": 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

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.Dec 9 2013, 7:45 PM

• werner added a project: Feature Request.

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.

gnupg chooses an outdated keyOpen, WishlistPublicActions

Description

Details

Event Timeline

gnupg chooses an outdated key
Open, WishlistPublic
Actions