reader configuration partially skipped If SCardControl missing

[frankmorgner]

When
SCardControl(card_handle, CM_IOCTL_GET_FEATURE_REQUEST,... fails at:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1153

the 178 lines of code:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1158-L1337
are not executed, which includes:

• code to test for specific readers
• pin pad info (probably why pin pad readers don't work in Windows)
• part10_detect_pace_capabilities(reader, card_handle);
• max_send_size = max_recv_size = part10_detect_max_data(reader, card_handle);
• other code to set max_send_size and max_recv_size which may end in "Assuming that the reader supports sending short length APDUs only"

This results in a card driver like card-sc-hsm.c expects the reader in the token to support extended APDUs that the reader does not.

This lack of the features from PCSClite in the Windows implementation could be addressed if OpenSC took some of the changes from PCSClite to fill in info for readers. Or at least look in opensc.conf

This problem may be the same problem as in #3004 and other card drivers may have similar problems.

(I actually found that building OpenSC from github using Cygwin was easy and could debug using gdb)

Originally posted by @dengert in #2944 (comment)

[metsma]

For the record apple has switched to their CCID driver and they did not support SCardControl in 14.0/14.1.
https://blog.apdu.fr/posts/2023/11/apple-own-ccid-driver-in-sonoma/
In the 14.2 they switched back to @LudovicRousseau CCID driver.
In 14.3 they implemented SCardControl in some extent and switched back to their own CCID implementation.
Least PinPAD is working but I am not sure about APDU size parameters. (@LudovicRousseau maybe you can verify this also their driver misidentifies some card readers as pinpads #1438)

[frankmorgner]

does dlopen on macOS' pcsc implementation yield NULL when requesting SCardControl or do they implement it by always returning an error? In the former case, this may be the reason for #2788 ...

[metsma]

does dlopen on macOS' pcsc implementation yield NULL when requesting SCardControl or do they implement it by always returning an error? In the former case, this may be the reason for #2788 ...

They return SCARD_E_NOT_TRANSACTED (https://blog.apdu.fr/posts/2023/09/macos-sonoma-bug-scardcontrol-returns-scard_e_not_transacted/)

[frankmorgner]

then this is not related to the segfault, thanks

[dengert]

@LudovicRousseau
OpenSC is over 20 years old. Back then there where readers that did not ever support max sizes of 255/256.

Today are there any readers that do not support extended APDU?

If we can not get PCSCv2_PART10_PROPERTY_dwMaxAPDUDataSize should default be the reader can support something like at least 1023/1024?

Is there any reader command to get the max size or at least show if extend is supported?

Could a mod be added to apdu.c that if card supports extended but a command requesting extended fails because the reader does not support extended, apdu.c or the card driver could reset the sizes and try again without extended?

[LudovicRousseau]

In 14.3 they implemented SCardControl in some extent and switched back to their own CCID implementation. Least PinPAD is working but I am not sure about APDU size parameters.

Apple made some progress in the SCardControl() implementation of their own CCID driver. But it is not yet ready.
See https://blog.apdu.fr/posts/2024/02/macos-sonoma-bug-scardcontrol-part-2/

[LudovicRousseau]

Today are there any readers that do not support extended APDU?

Yes. See https://ccid.apdu.fr/select_readers/?dwFeatures=13
A lot of them are tokens and nor readers so you can't use them with a smart card.

I would say most of these readers are "old" but may still be used in the field.

If we can not get PCSCv2_PART10_PROPERTY_dwMaxAPDUDataSize should default be the reader can support something like at least 1023/1024?

I think that is a safe choice.
It will fail with non-extended APDU readers if the card requires extended APDU. But this combination would fail whatever you do.

Is there any reader command to get the max size or at least show if extend is supported?

Not at the PC/SC level except PCSCv2_PART10_PROPERTY_dwMaxAPDUDataSize.

Could a mod be added to apdu.c that if card supports extended but a command requesting extended fails because the reader does not support extended, apdu.c or the card driver could reset the sizes and try again without extended?

You can try something like that.