If this is pursued, I suggest doing it as a subsystem external to GnuPG. GnuPG
can generate keyserver information files (via --keyserver-options
use-temp-files). An external program can gather these files and manage them
however it likes, then pass them to the keyserver helper programs when it is
ready to.

Given that you are using an SVN version, you should definitely take this bug
report to the mailing list. Please include a typescript so that it will be
clearer what the problem ist.

You need to specify the reader using

I've forgotten, just for your information, I've no cherry or omnikey support
request answer at this time.

I've said that on T1094 (tsndcb on Jul 30 2009, 12:35 AM / Roundup), when I generate directly my keys by the smartcard, It
ask me if I want to backup it, if I answer yes => failure (and no generate keys
are done), If I answer no, my key are generated but I've no keys backup.

I am not sure I understand this. Do you mean a failure while writing an
off-card generated key to the card? That is fixed with 03-opgp-writekey.patch .

Do you've also a patch for backup failure when generate key on smartcard ?

I have not seen that card yet. Thus I can't tell.

I've done a support request to cherry and omnikey, but actually I've no answer
about it ... :-(

Sorry for the late response, only recently a new pinentry got released.
So we will test this on basis of 0.7.6.

No response - assuming that everything is fine now.

I'd say the problems are due to the Cherry XX44. We need to contact the vendor.
I'll try it again this week.

I see. Your plaintext needs to be zeroized after decryption and processing by
you. gpgme does not directly support this. What you can do for data objects
hold in memory is:

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.

Forwarding for Bill.

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 :

Wrong title. It is not that the password is visible but that the clear text
from the gpgme_opt_decrypt function is visible. Another developer with more
knowledge of the scenario in this issue will respond shortly.

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 :

static int scrub_stack()
{
char arr[8192];

So you are using the passpharse callback of gpgme and don't make use
ofgpg-agent. In that case you need to take care of zeroing the passphrase.
gpgme has no provisionhs for this because the passphrase callback is a feature
obnly useful in certain environments. gpgme_data_t has nothing to do with
passpphrases.

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.

Duplicate of T1095

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