FWIW,
the issue might be related to a key form Gentoo, which was expired but was then later renewed (at least it is no longer expired).

It even worked now (few hours later) :

here is the the brooad key, which cannot be deleted.

On 08/27/2015 06:21 PM, Werner Koch via BTS wrote:

Hey, why are you adding an X.509 DN to the key?

It's not my key - I do not even know how to do that ;)

On 08/27/2015 03:55 PM, Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

What do you mean by "remove"? "delete key"?

On 07/03/2014 11:30 AM, Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

That is OpenSSL and not GnuPG.

---

category: -> trash
status: unread -> resolved
topic: +mistaken

---

g10 Code's BTS <gnupg@bugs.g10code.com>
<T1663>

---

yes - I
I'll repoet this to OpenSSL - pls close this as PEBKAC.
sry.

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

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).

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

Gentoo thinks about patching its package with their own solution till an
official fix :
https://bugs.gentoo.org/show_bug.cgi?id=442568#add_comment

Gentoo devs identified an issue in the source code :

TIt is a 3.6.6 vanilla kernel of a stable Gentoo with 3.6.6 vanilla kernel and
gcc-4.6.3 (+ Gentoo patch set), all options are here :
https://bugs.gentoo.org/show_bug.cgi?id=442568#c0

and there's the complete build log attached too (gzip'ed - the mime type might
be sometimes not recognized correctly)

quick bisecting gave :

tfoerste@n22 ~/devel/libgcrypt $ git bisect bad
83f80d39c3feddc7e055525d47dcf3f069801e89 is the first bad commit
commit 83f80d39c3feddc7e055525d47dcf3f069801e89
Author: Werner Koch <wk@gnupg.org>
Date: Tue Feb 15 14:38:02 2011 +0100

    Change more AES-NI code into plain asm

:040000 040000 5f3aef9e672defe8feeec28e4c6aa2b810c7e0e8
01816387886d3d8e832d0a97e1e0f1a984fa9256 M cipher