diff options
author | NIIBE Yutaka <[email protected]> | 2017-03-27 02:25:00 +0000 |
---|---|---|
committer | NIIBE Yutaka <[email protected]> | 2017-03-27 02:25:00 +0000 |
commit | 0848cfcce738150b53bfb65b78efc1e6dc9f3d26 (patch) | |
tree | 8963ca0113c698c6e0fa25cd21089897084c4d72 | |
parent | gpg: Improve check for already compressed packets. (diff) | |
download | gnupg-0848cfcce738150b53bfb65b78efc1e6dc9f3d26.tar.gz gnupg-0848cfcce738150b53bfb65b78efc1e6dc9f3d26.zip |
scd: Fix timeout handling for key generation.
* scd/ccid-driver.c (CCID_CMD_TIMEOUT): Back to original value.
(CCID_CMD_TIMEOUT_LONGER): New.
(ccid_transceive): Add kludge for key generation.
--
At key generation of longer key size, OpenPGP card sends back "time
extension" with BWI=100, which is unusual value in the protocol and it
actually requires host having longer timeout like 43 seconds.
Reported-by: Szczepan Zalega <[email protected]>
Fixes-commit: 6510df3a7cd2b5bf44fac1e4d50ee54b8c897daa
Signed-off-by: NIIBE Yutaka <[email protected]>
Diffstat (limited to '')
-rw-r--r-- | scd/ccid-driver.c | 18 |
1 files changed, 13 insertions, 5 deletions
diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 40b25991e..a471adf79 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -108,8 +108,10 @@ */ #define CCID_MAX_BUF (2048+7+10) -/* CCID command timeout. OpenPGPcard v2.1 requires timeout of 13 seconds. */ -#define CCID_CMD_TIMEOUT (13*1000) +/* CCID command timeout. */ +#define CCID_CMD_TIMEOUT (5*1000) +/* OpenPGPcard v2.1 requires huge timeout for key generation. */ +#define CCID_CMD_TIMEOUT_LONGER (60*1000) /* Depending on how this source is used we either define our error output to go to stderr or to the GnuPG based logging functions. We @@ -3394,6 +3396,7 @@ ccid_transceive (ccid_driver_t handle, int retries = 0; int resyncing = 0; int nad_byte; + int wait_more = 0; if (!nresp) nresp = &dummy_nresp; @@ -3407,7 +3410,7 @@ ccid_transceive (ccid_driver_t handle, but the Windows driver does it this way. Tested using a CM6121. This method works also for the Cherry XX44 keyboards; however there are problems with the - ccid_tranceive_secure which leads to a loss of sync on the + ccid_transceive_secure which leads to a loss of sync on the CCID level. If Cherry wants to make their keyboard work again, they should hand over some docs. */ if ((handle->id_vendor == VENDOR_OMNIKEY @@ -3503,8 +3506,8 @@ ccid_transceive (ccid_driver_t handle, msg = recv_buffer; rc = bulk_in (handle, msg, sizeof recv_buffer, &msglen, - via_escape? RDR_to_PC_Escape : RDR_to_PC_DataBlock, - seqno, CCID_CMD_TIMEOUT, 0); + via_escape? RDR_to_PC_Escape : RDR_to_PC_DataBlock, seqno, + wait_more? CCID_CMD_TIMEOUT_LONGER: CCID_CMD_TIMEOUT, 0); if (rc) return rc; @@ -3678,6 +3681,11 @@ ccid_transceive (ccid_driver_t handle, { /* Wait time extension request. */ unsigned char bwi = tpdu[3]; + + /* Check if it's unsual value which can't be expressed in ATR. */ + if (bwi > 15) + wait_more = 1; + msg = send_buffer; tpdu = msg + hdrlen; tpdu[0] = nad_byte; |