My understanding is: it was introduced by rG370f841a0135: Enhanced last patch. in 2009 to give information to client (for a specific command at that time), possibly in a hope that server side would support the feature for all commands (and client could benefits).

Thanks. So, this is a positive report for 8E60:34C2. I'm going to add this VID:PID to support pinpad input by the internal CCID driver.

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

I'm going to push this change to master.

I was afraid that there are wrong usage where HANDLE is passed where int for fd is expected (or opposite).
But it seems, there are only usage where it should be gnupg_fd_t ideally but using int.

I'd like to push your change to master, if possible with exact check.
Do you intend to put your comment to the master repo? Or, it's for discussion?
It's OK for your topic branch, but, I feel that it would be too long to be included to master repo.

I'm confusing if following API should use gnupg_fd_t or not:

• iobuf_fdopen, iobuf_fdopen_nc
  • Perhaps, these are using int for fd, like es_fdopen
• set_attrib_fd ?
• read_passphrase_from_fd ?
• set_status_fd ?
• is_secured_file ?

As far as I know, usually, gpg/gpgsm can assume same version of gpg-agent.

I pushed a fix to master: rG858dc9564326: scd: Fix bBWI value.

Except w32_system function, it's done.

APIs which need revise (where we use pid_t):

API which uses int for fd:
GnuPG common:

• gnupg_create_pipe, gnupg_create_outbound_pipe, gnupg_create_inbound_pipe
• gnupg_spawn_process_fd

gpgrt:

• gpgrt_make_pipe (not yet exposed to public API)
• gpgrt_spawn_process_fd (not yet exposed to public API)

HANDLE type casting to long is wrong (it results masking the value to 32-bit, which is not needed).
I fixed:

• rGa64411c607d5: common,w32: Fix cast from gnupg_fd_t to call _open_osfhandle.
• rE655ed9d83889: w32: Fix HANDLE to internal fd conversion.
• rEf93a0358dc82: w32: Fix cast to internal fd.

I see your point (I am also the one who implements reader/token). That's reasonable argument.

Thanks for your report, with helpful log.

Backported.

I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).

In general, if it requires more time, a reader can reply with time extension.

What's Trustica Cryptoucan?
In general, if it requires more time, a reader can reply with time extension.

FYI, we have "factory-reset" command in gpg --card-edit; It is not enough for a card to have admin locked state, but it requires normal user locked state, too.

Yes: at least 255 times.

Patch is pushed to master. Will be backported to 2.2.

It responds somehow, but the content has invalid data of (bChainParameter=0x04):

2019-07-05 09:36:41 scdaemon[71407] DBG: chan_17 -> S LOGIN-DATA aheinecke
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 21
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 4
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 21
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bChainParameter ...: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 82 00 82
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 22
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 4
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 22
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bChainParameter ...: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 82 00 82
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 23
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:46 scdaemon[71407] DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT
2019-07-05 09:36:46 scdaemon[71407] ccid_transceive failed: (0x1000a)
2019-07-05 09:36:46 scdaemon[71407] apdu_send_simple(1) failed: card I/O error

After the cancellation, the card reader seems being screwed up:

It is canceled:

2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 19
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 64
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bError ............: 239
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: CCID command failed: PIN cancelled
2019-07-05 09:36:41 scdaemon[71407] DBG: dismiss pinpad entry prompt
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> INQUIRE DISMISSPINPADPROMPT
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 <- END
2019-07-05 09:36:41 scdaemon[71407] verify CHV2 failed: Invalid response
2019-07-05 09:36:41 scdaemon[71407] operation decipher result: Invalid response
2019-07-05 09:36:41 scdaemon[71407] app_decipher failed: Invalid response
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> ERR 100663372 Invalid response <SCD>

Please note that key generation is takes time unusually longer from a viewpoint of card reader.
It is possible for a card reader to give up the execution of key generation command as timeout.

I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.

Thank you. Merged.

Sorry, perhaps, I misunderstood how SKESK packets are generated in your application.
I was considering there were 256 recipients.

If the use of GnuPG (current implementation) is a condition, I think that you could improve the generation of SKESK packets, so that no other passphrase can let gpg misunderstand as it may decrypt encrypted packet.

Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.

Thanks.
Merged (with line break in the Makefile.am and formatting of commit message.

I mean, if all SKESK packets should be tried, we need some larger surgery of current implementation.

Is it possible for your application (DOTS), to specify the packet number for SKESKP, not trying all SKESK packets?

It was rG07250279e7ec: * keyedit.c (keyedit_menu): Invisible alias "passwd" as "password". in 2004, which set default to rfc2440-text behavior.
And in 2007, the commit rGb550330067b6: * gpg.c (main): Disable --rfc2440-text and --force-v3-sigs by default. changed the default to no-rfc2440-text.

Thanks, fixed in master.

Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.

While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.

In the current implementation of GnuPG, multiple packets of Symmetric-Key Encrypted Session Key Packet are not handled very well.

Pushed the change to master as well as 2.2 branch.

About importing, there are two other works: repairing and trustdb update. We can figure out the difference by the --import-options of no-repair-keys and fast-import (to skip those works).
I think that both can be O(N^2) for number of signatures.

I disabled the dependency rules for the figures (it's only enabled for maintainers).

Fixed.