Please explain in more detail what you are doing. And well we don't have
support for Windows7 yet. According to user reports it seems to work but we
don't have first-hand knowledge. Windows7 hardware arrived only recently.

Please ask on the ML for advise.

STABLE-BRANCH-2-0 344d72b
has the fix.

Duplicate of T1203

Please don't attach files in a more or less proprietary format. We will only
accept plain text files. Further the bug description should be a message and
not an attached file. File may be attached for test data or if you want to
provide long log data.

You are right, that is faulty. The correct code is:

Please don't put bugs into the BTS for a development version. Use the
gnupg-devel@ mailing list instead.

I did some more research (I think I can localize the GPG code where the problem
happens, and currently I conclude that it is really a Windows bug) and wrote up
my findings in the attached file GnuPGRenamingBug.rtf, from where you can
download everything and print it out.

additional information:
gpg4win (2.1) is installed on a Microsoft Windows 7 Client

Use the pdf version.
An info file will be installed with gnupg.

D144: 317_gnupg-2.1-liblber.patch

Should probably beretested with Gnupg 2.1(beta or later)
because agent startup might have changed.

The fix in 1.4.11 did not work. See
http://lists.gnupg.org/pipermail/gnupg-devel/2010-October/025805.html
for a working patch.

Hello,
libgcrypt 1.4.6

2.1 will fix that.

What version of libgcrypt are you using (gpg-agent --version)?

Thanks for testing.

Testing suggests that the "can't connect my own socket: Invalid value passed to
IPC" gpg-agent issue has been resolved.

Revision 389 compiled fine - many thanks!

Hello Werner,

Hallo Werner!

For the given use case you should ask the former employee to revoke the uid.
And in case you can't contact him, the signers may revoke their signatures
(--edit-key, "revsig").

D139: 315_stable-2-0.diff

Oops cruft in the stable-2-0.diff use this version instead and delete the first one.

STABLE-2-0.diff

D140: 314_stable-2-0.diff

STABLE-1-4 patch

D141: 313_stable-1-4.diff

D142: 312_trunk.diff

A colleague just observed that expiration dates are also missing when
--list-secret-keys is used without a matching string.

I would just like to add that this problem only happens when gpg-agent is _not_
being used, and it disappears completely if gpg-agent is used.

Well, ce-server.c is code we used for some tests on WindowsCE. There is no need
to build it on other platforms. I disabled building ce-server.

Any update?!?

The problem was an old /tmp/keyring-RT77ms which contained three file: control,
gpg and pkcs11. I think this happened when I had both an Openpgp card and a
PKCS#11 plugged in at the same time. At that time I ran a gpg --card-status and I
could see that two cards were detected but I was not able to access the OpenPGP
one.

Shame on me. I have use_agent in my gpg.conf but don't have the gpg-agent
started. Commenting out this line gave me access to the card again. This is weird
because earlier today I would get a simple warning about missing gpg-agent and
that /tmp/xxx is not available.

As I already explained: It works for me using the qt pinentry!

The release pinentry 0.8.0 version (from 2010-03-03) is based on svn222 (see
tags(pinentry-0.8.0).

Use the released 0.8.0 qt pinentry and not some earlier (i.e. -svnXXX versions).

Because we have not done a regular release yet. However a release candidate has
been published: (cf. ftp://ftp.gcrypt.org:gcrypt/alpha/gnupg01.4.11rc1.tar.bz2)

This has been fixed in the SVN.

Changed to "the following key" for GnuPG 2.0 and 2.1.

Hum, so why am i having this bug while running the last version of gnupg?

Just to make sure:
I tested with gnupg 2.0.16 + pinentry 0.8.0-svn234.
You say that I should test gnupg 2.0.16 + pinentry 0.8.0-svn237.
Right?
(But in T1237 (wk on Sep 28 2010, 01:05 PM / Roundup) you wrote: "you need a newer gnupg".)

2.0.16 should be sufficient, though. Just use a recent pinentry-qt.