In fact, with more tests, I can't read on Windows XP my keys generated on my
linux ...
I can only see the fingerprint nothing else.

I've some good news for you and me :-)

I've make again my package gnupg2 and installed it, this time all patchs was
applied, but I've always the same error :

To solve the third error I've done that :

1. cd scd (I've delete cd scd && on 06-opgp-sign3072.patch file)
2. sh ./06-opgp-sign3072.patch

patching file iso7816.c
patching file app-openpgp.c
patching file iso7816.h
patching file app-dinsig.c
patching file app-nks.c
patching file app-p15.c

Yes I've do it, but I've an error for the third :

Did you applied the patches?

I've done news tests on a "fresh" debian install, I've installed gnupg2 2.0.12,
gpg-agent 2.0.12, gpgsm 2.0.12, pinentry-curses 0.7.5-3 and pinentry-gtk2 0.7.3-3.

[In may previous message I meant "gpg does not _wait_ for the end ..."]

When I've done my tests yesterday, pinentry-gtk2 (0.7.5-3) was installed, and
version 2.0.11 of gnupg2 worked fine with it.

I noticed that the status of this issue was changed to resolved and was
wondering if that meant that it will work in a future version of gnupg or if
it means that nothing will/can be done for the Windows version, i.e. a disk
write will be required each time, and the issue is just closed?

You need to install the pinentry package as weel.

I've compiled and installed the new 2.0.12 gnupg version.

Thanks, werner for patchs, I'm on debian, so I think I need it.
Windows xp was just to tested, because generate key doesn't work on my debian,
I'm work on debian squeeze.

These are the non Windows patches we are going to use in gpg4win 2.0.0. They
can be applied to a plain 2.0.12.

I posted them to the mailing list but there are no direct links. Thus I add
them to this bug report.

Many thanks for your answers.

In addition all Omnikey based readers (e.g. the Cherry keyboard) can't cope with
2048 bit keys. The Omnikey windows driver has a workaround. I reversed
engineered parts of that protocol, so that 2.0.13 works a little bit with these
readers if use with the internal ccid driver (i.e. w/o pcscd).

This version does not support the v2 smartcard.

Enabling CMX_DEBUG should also give some insights.

What I noticed is that the driver uses a write timeout of (3*hz) for the CCID
ESCAPE command but (150*hz) for XFRBLOCK. My hack now uses the ESCAPE command
to send extended length APDU data blocks and they resemble what XFRBLOCK does.
My next test would be to change the timeout for the ESCAPE command in
cmx_timeout_by_cmd - I don't know whether this helps.

Werner Koch via BTS wrote:

I guess I should look at the freebsd driver. Any hint where to find
it in the freebsd svn?

I guess I should look at the freebsd driver. Any hint where to find it in the
freebsd svn?

Werner Koch via BTS wrote:

Pth bug? Please try again after putting debug-disable-ticker
into scdaemon.conf.

Done. (rev 5092).

Pth bug? Please try again after putting

<snip>

indicates that you are using a real USB device. abort_cmd should
terminate with an error if used on a non-USB device.

Will this be backported to 1.4 as well?

Applied to 5089. Thanks.

No, --fix-trustdb is a hidden command and may get a new life in the future.

Thanks for the change, I will check it out.
Did you consider removing the option --fix-trustdb
if you do not intend to implement it?
I would consider removal to be good, if the warning
is all what people get in the foreseeable future.
The existance of the options assumes that there is code
to do the fixing behind it.

Fixed in svn 5087.

An admin saw this suggestion in front of a user and got annoyed
that the recommendation

"the trustdb is corrupted; please run \"gpg --fix-trustdb\".\n") );

in tdbio_invalid(void) gnupg-2.0.12 did not work.

Are you still using the 4040?

Werner Koch via BTS wrote:

If that all does not help, a log file from gpg-agent would be useful.
Required options gpg-agent.conf are the log-file and "debug 1024".

Fixed in svn 5083. Will be backported to 1.4 if needed.
Thanks.

Done for 2.0 in svn r5082; will also be packaged with gnupg 1.4.10.

We can't print an error message because that would let gpg treturn with an error
code and lead to problesm with scripts which assume the current way of doing
things. A warning is possible but Unix tools generally don't do that.

D100: 235_issue1091.diff

I looked at the source code and believe to have found the problem. Attached is a
diff against the latest svn that fixes this issue.

Werner Koch via BTS wrote:

Are you sure that you are using the latest gpg-agent;

Are you sure that you are using the latest gpg-agent; i./e. that which comes
with the SVN version of GnuPG? The easiest way to use a nwer gpg-agent trhan
one that is already running is by using

Werner Koch via BTS wrote:

However, I reverse engineered the protocol used by the Windows driver
and figured out how that driver does it. The SVN version has a hack
which basically works. I tested the 4040 and it works in most cases.
The hack is not 100% reliable but I was able to generate and use keys.

For obvious reasons the mailto scheme is not very useful. It is not even build
by default; you have to use ./configure --enabe-mailto. OTOH, I see that a way
to batch up keys for later retrieval is a nice feature - it should hwoever not
be limited to the mailto scheme.

Sorry, Omnikey based readers are broken for keys >= ~ 2048 bit. See
http://pcsclite.alioth.debian.org/ccid_extended_apdu.html . The 4040 might not
be listed but it uses the same chip and doesn't work either.

UID are expected to be UTF-8, IDN conversion should be done by the MUA.

Already fixed in my working copy. Will be commited with other translation
changes later the week.

Fixed in SVN. Thanks.

not a bug or - if at all - a bug in glibc. Further discussion please on the ML

Will be released with 1.4.10.

You can change the location of the keystore by cetting the environment variable
GNUPGHOME.