security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2024-12-22 10:19:57 +01:00
Code Activity

fix wLangId in ccid-driver.c

Browse Source 
This is not a part of pin pad support series of mine.

As I found the bug while I am preparing the patches, I report this.

As CCID protocol is little endian, wLangId of US English = 0x0409
is represented as two bytes of 0x09 then 0x04.

It is really confusing that the code like following is floating
around:
	pin_verify -> wLangId = HOST_TO_CCID_16(0x0904);

But, it is 0x0409 (not 0x0904).  It is defined in the documentation:

    http://www.usb.org/developers/docs/USB_LANGIDs.pdf

and origin of this table is Microsoft.  We can see it at:

    http://msdn.microsoft.com/en-us/library/bb165625%28VS.80%29.aspx

Yes, it would be better not to hard-code 0x0409.  It would be better
to try current locale of the user, or to use the first entry of string
descriptor.  I don't have time to implement such a thing...
This commit is contained in:
NIIBE Yutaka 2011-01-13 16:38:31 +09:00
parent b8d7b33d69
commit dafa7aa621
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
scd/ccid-driver.c
View File

@ -3133,8 +3133,8 @@ ccid_transceive_secure (ccid_driver_t handle,
if (pinlen_min && pinlen_max && pinlen_min == pinlen_max)
msg[17] |= 0x01; /* Max size reached. */
msg[18] = 0xff; /* bNumberMessage: Default. */
msg[19] = 0x04; /* wLangId-High. */
msg[20] = 0x09; /* wLangId-Low: English FIXME: use the first entry. */
msg[19] = 0x09; /* wLangId-Low: English FIXME: use the first entry. */
msg[20] = 0x04; /* wLangId-High. */
msg[21] = 0; /* bMsgIndex. */
/* bTeoProlog follows: */
msg[22] = handle->nonnull_nad? ((1 << 4) | 0): 0;