reader configuration partially skipped If SCardControl missing about opensc HOT 7 CLOSED

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/)

from opensc.

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)

from opensc.

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

from opensc.

then this is not related to the segfault, thanks

from opensc.

@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?

from opensc.

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/

from opensc.

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.

from opensc.