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 ... :-(

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.

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

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.

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

Okay, okay, I remove the "pub/".

Then why is it referenced in multiple locations in the GnuPG website?!

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.

Well, I have no more excuses at hand to actually look at the problem ;-).

well. I tried.

See the INSTALL file for another way to share defaults (section "Sharing Defaults").

No. CFLAGS is used to override default flags. It might be that in a BSD system
CFLAGS can be used in the way you describe it; with the GNU system this is not
the case.

However, if CFLAGS is set in the environment previously, configure will fail.
This is especially inconveniently for those who set CFLAGS in bashrc etc and
those who uses source-based package manager doing this.
Setting CFLAGS as an environment variable should be universally correct,
shouldn't it?

No, that is not a typo. --daemon used to be required to avoid starting several
gpg-agents - which happened quite often while in lets-see-what-happens testing
mode. Later the code was change so that running gpg-agent without any args
tested whether a gpg-agent is already running. Thus we can simplify the paragraph.

It is basically the same code as used in gpg2. On a GNU system tty_get_ttyname
always returns "/dev/tty". This is used as a fallback solution so that we can
tell gpg-agent at least one tty which may work.

Use

gpa --version

on the command line. We have the rework of the help menu on our todo list, thus
I close this bug.

I know, however the checks do only basic checking and reject more exotic
addresses. Actually the specs don't say anything about the format of a user ID;
it is just a convention that they resemble a mail address.

GnuPG Shell is, and always has been, released under the GNU General Public
License.

I understand. Such a diagnostic is of course possible.

If we use "--multifile --sign", we got an error message:
gpg: --sign does not yet work with --multifile

I searched for '-'s and they are only on the BEGIN and END message lines. The
encrypted file is over 350K, this is the tail of the file:

There is some garbage at the end of the file. I can't tell you more without
seeing the encrypted file. ctb=2dmeans that a '-' has been detected. A possible
reason for this is a broken MIME parser.

Thank you for the information, with it I will be able to alter behaviour on the
fly (via system variable) but anyway, it would be really great gpg could pass
an argument -- I think it is a bit more elegant way to control the behaviour.