Fixed in 1.4 since 2009-07-23.
Released with 1.4.10.

Fixed for 2.0.x in svn 5144.

Yes, it is the same code.

I was using gnupg2 during these tests, was that affected by the APDU field size
issue?

There is one bug in gpg: The Le field of the APDU is set to 256 but we expect a
larger return value. I fixed that problem in the just released 1.4.10.

Fixed in 1.4.10 - just released.

That might be a problem in libbz2 or in our glue code.

Does the fact that I can encrypt, sign, and authenticate correctly with 3072 bit
keys affect your hypothesis?

According to http://pcsclite.alioth.debian.org/supported.html#0x17EF0x1003
this is a supported reader. I will have a closer look at your log file tomorrow.

Here's the output from lsusb:

What reader are you using? USB vendor and product id (lsusb).

According to http://pcsclite.alioth.debian.org/shouldwork.html#0x0B970x7762
this reader should work but it has not been tested.

I close this issue, thanks again

We will never get 1.4.10 out if you guys always find bugs :-)

This is not a bug. See the chapter on how to specify a user ID. An 8 character
long string all consisting of valid hex characters is considered a key ID (in
your case 0x0564B63A). There are explicit ways to mark a user ID; for example:

No time to look into this. Hints on how to fix this are of course welcomes

Sorry, I typoed, it was 3072R that I generated and failed to use. Its the same
type of key used in T1105. A 2048R key works
fine.

And why you won't fix it?

I was about to write: That is known and we won't fix it. That it works in
1.4.9 is interesting. I need to look at it.

Is "3074G bit" a type or do you really try to use an Elgamal key? The card does
only support RSA keys.

Is there any more information I can provide? Can you reproduce it?

I did some more debugging on this, it seems something can't handle the large
APDU messages generated when doing decryption with a 3072-bit key. Checking the
ISO documentation, a 64xx error is an execution error, so it seems either a bad
request is going to the card, or the card simply can't handle a long message:

I had a go at doing this in sections. I used:

Agreed for the manual page. We will think about this.

I leave this decision to you. I agree to the reporter, that everything is a bit
"wildly" ordered atm. However, I cannot speak for an unexperienced user. I've
asked the reported for feedback/his opinion.

That would be hard to implement. Consider that an alpahbetic order makes most
sense only to English speaking users, whereas others will likely use the
translated description.

I can now make gpg key backup during generated key directly on the opengpg V2
smartcard.

This is the built-in reader in my Dell Latitude D430, by the way.

This is the relevant lsusb output:

Fixed in svn 5123. I fixed that a year ago in trunk and forgot to backport it.

Fixed again. (svn 5122).

Indeed, I applied it only to gnupg-2. Applied it to 1.4 now.

Ooops, I missed to copy the included files. I added a new make traget to assist
me in the future.

What card reader are you using?

Unfortunately still not fixed in 1.4.10 rc1.

Sorry, this was the wrong report. #917 is still open.

It seems, the buggy translation had been reintroduced:

Did 1.4. Will do 2.0 shortly, after a bit of testing.

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.

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

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