MUSCLE mailing list statistics for 2015

As I did in 2009, 2010, 2011, 2012, 2013 and 2014 I propose some statistics of the MUSCLE mailing list usage.

Evolution

Year Total number of messages Progression
2009 603
2010 718 +19 %
2011 999 +39 %
2012 207 -79 %
2013 198 -4 %
2014 194 -2 %
2014 194 -2 %
2015 120 -38 %

The number of messages is declining. At the same time I get more requests by email.

My interpretation is that the software pcsc-lite, libccid, etc. are stable now. But people have problems using it. That could also explain why the sample code articles have success (see my previous article "Happy new year 2016").

Comments

I am still the top poster on the MUSCLE mailing list with 33% of the messages.

The second top poster is Fabrice DIMITRIOU (fdimitriou@tmm-software.com) with 12 "Out of office" messages and the most successful subject. Well done Fabrice ☺.



Statistics from 20.1.2015 to 31.12.2015
for pcsclite-muscle@lists.alioth.debian.org



People who have written most messages:

   Author   Msg   Percent 
1 ludovic.rousseau@gmail.com 40 33.33 %
2 fdimitriou@tmm-software.com 12 10.00 %
3 bill.c.roberts@gmail.com 8 6.67 %
4 guy@linux-service.be 7 5.83 %
5 rickyepoderi@yahoo.es 5 4.17 %
6 henrik@synth.no 4 3.33 %
7 fdeybach@gmail.com 4 3.33 %
8 Jindrich.Mican@lgnexera.at 3 2.50 %
9 morgner@informatik.hu-berlin.de 3 2.50 %
10 EHeck@intarsys.de 3 2.50 %
11 william.to@erg.com.hk 3 2.50 %
12 martin@martinpaljak.net 2 1.67 %
13 moshman@gmail.com 2 1.67 %
14 orzel@freehackers.org 2 1.67 %
15 elbuffo166@gmail.com 2 1.67 %
16 saper@saper.info 2 1.67 %
17 marian.thieme@gmail.com 2 1.67 %
18 gdt@ir.bbn.com 1 0.83 %
19 jhutz@cmu.edu 1 0.83 %
20 bbsoo7@live.com 1 0.83 %
21 pcsclite.pkoch@dfgh.net 1 0.83 %
22 russ@garrett.co.uk 1 0.83 %
23 info@boac.nl 1 0.83 %
24 helpcrypto@gmail.com 1 0.83 %
25 Tom.Arnautovic@neardesk.com 1 0.83 %
26 crack.nyse@gmail.com 1 0.83 %
27 luc.mazardo@orange.com 1 0.83 %
28 Pcsclite-muscle =
1 0.83 %
29 Herve.CODINA@celad.com 1 0.83 %
30 nicksp@gmail.com 1 0.83 %
  other 3 2.50 %

Best authors, by total size of their messages (w/o quoting):

   Author   KBytes 
1 ludovic.rousseau@gmail.com 296.6
2 fdimitriou@tmm-software.com 102.6
3 bill.c.roberts@gmail.com 83.0
4 guy@linux-service.be 53.8
5 Tom.Arnautovic@neardesk.com 45.1
6 EHeck@intarsys.de 29.4
7 rickyepoderi@yahoo.es 28.8
8 william.to@erg.com.hk 23.4
9 morgner@informatik.hu-berlin.de 22.1
10 martin@martinpaljak.net 20.7
11 orzel@freehackers.org 18.3
12 Herve.CODINA@celad.com 16.2
13 henrik@synth.no 15.3
14 fdeybach@gmail.com 13.6
15 ignacio.casal@nice-software.com 13.6
16 helpcrypto@gmail.com 10.7
17 saper@saper.info 10.6
18 elbuffo166@gmail.com 10.4
19 Jindrich.Mican@lgnexera.at 9.2
20 bbsoo7@live.com 8.8
21 marian.thieme@gmail.com 8.5
22 Pcsclite-muscle =
8.5
23 gdt@ir.bbn.com 8.3
24 moshman@gmail.com 7.7
25 godfreyhkchung@gmail.com 7.0
26 luc.mazardo@orange.com 6.9
27 mkl@pengutronix.de 6.6
28 crack.nyse@gmail.com 5.2
29 russ@garrett.co.uk 5.0
30 nicksp@gmail.com 2.1

Best authors, by average size of their message (w/o quoting):

   Author   bytes 
1 Tom.Arnautovic@neardesk.com 46175
2 Herve.CODINA@celad.com 16576
3 ignacio.casal@nice-software.com 13877
4 helpcrypto@gmail.com 10974
5 bill.c.roberts@gmail.com 10625
6 martin@martinpaljak.net 10576
7 EHeck@intarsys.de 10019
8 orzel@freehackers.org 9351
9 bbsoo7@live.com 8967
10 fdimitriou@tmm-software.com 8758
11 Pcsclite-muscle =
8680
12 gdt@ir.bbn.com 8473
13 william.to@erg.com.hk 7978
14 guy@linux-service.be 7872
15 ludovic.rousseau@gmail.com 7593
16 morgner@informatik.hu-berlin.de 7559
17 godfreyhkchung@gmail.com 7120
18 luc.mazardo@orange.com 7066
19 mkl@pengutronix.de 6797
20 rickyepoderi@yahoo.es 5890
21 saper@saper.info 5448
22 elbuffo166@gmail.com 5324
23 crack.nyse@gmail.com 5316
24 russ@garrett.co.uk 5146
25 marian.thieme@gmail.com 4362
26 moshman@gmail.com 3918
27 henrik@synth.no 3906
28 fdeybach@gmail.com 3480
29 Jindrich.Mican@lgnexera.at 3136
30 nicksp@gmail.com 2172

Table showing the most successful subjects:

   Subject   Msg   Percent 
1 [Pcsclite-muscle] Absence du bureau / Out of the office
13 10.83 %
2 [Pcsclite-muscle] IFD polling
11 9.17 %
3 [Pcsclite-muscle] pcscd segfaults
8 6.67 %
4 [Pcsclite-muscle] Authenticate on OSX with NFC
6 5.00 %
5 [Pcsclite-muscle] question about locking and reconnect
5 4.17 %
6 [Pcsclite-muscle] Possible data truncation on receive in 1.8.14
5 4.17 %
7 [Pcsclite-muscle] Failure to read Gemalto IDPrime MD with USB
4 3.33 %
8 [Pcsclite-muscle] Android Smart Card Emulator
3 2.50 %
9 [Pcsclite-muscle] Deny card access for one application
3 2.50 %
10 [Pcsclite-muscle] What is CLASS2_IOCTL_MAGIC?
3 2.50 %
11 [Pcsclite-muscle] Solaris 11 and pcsc-lite
3 2.50 %
12 [Pcsclite-muscle] [PATCH] ContextThread: SCARD_TRANSMIT: work
3 2.50 %
13 [Pcsclite-muscle] Semantics of
2 1.67 %
14 AW: Issue with pcsc-lite through rdesktop (share of scard to
2 1.67 %
15 [Pcsclite-muscle] Yubikey in OTP+U2F+CCID mode
2 1.67 %
16 pcsc-lite and polkit rules in openSUSE 13.2
2 1.67 %
17 [Pcsclite-muscle] Card Reader Issue
2 1.67 %
18 [Pcsclite-muscle] Error communicating to: GemPCTwin serial 00 00
2 1.67 %
19 [Pcsclite-muscle] Smartcard PAM module load failed after update
2 1.67 %
20 [Pcsclite-muscle] [PATCH 1/1] pcscdaemon: fix "at_exit() write()
2 1.67 %
21 [Pcsclite-muscle] OMNIKEY CardMan 5321 reader shown twice
2 1.67 %
22 [Pcsclite-muscle] Questions about supported devices page
2 1.67 %
23 [Pcsclite-muscle] Possibility to disable Reader Interface?
2 1.67 %
24 [Pcsclite-muscle] Feitian SCR301 - new version
2 1.67 %
25 [Pcsclite-muscle] Smartcard reader not detected on fedora 23
2 1.67 %
26 [Pcsclite-muscle] problems with rocketec reader
2 1.67 %
27 [Pcsclite-muscle] apdu4j - Java code and command line utility for
1 0.83 %
28 [Pcsclite-muscle] OSX - Yosemite - PCSC-Lite vs CryptoToken
1 0.83 %
29 [Pcsclite-muscle] questions for "Card auto power on and off"
1 0.83 %
30 [Pcsclite-muscle] TAG_IFD_POOLING_THREAD_WITH_TIMEOUT not
1 0.83 %
  other 21 17.50 %

Most used email clients:

   Mailer   Msg   Percent 
1 (unknown) 94 78.33 %
2 Mozilla/5.x 8 6.67 %
3 KMail 7 5.83 %
4 Postbox 3.0.11 (Macintosh/20140602)
2 1.67 %
5 Apple Mail (2.2070.4)
2 1.67 %
6 K-9 Mail for Android
2 1.67 %
7 Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.4 (berkeley-unix)
1 0.83 %
8 Evolution 3.10.4-0ubuntu2
1 0.83 %
9 Microsoft Outlook 15.0
1 0.83 %
10 git-send-email 1.7.9.5
1 0.83 %
11 Apple Mail (2.3096.5)
1 0.83 %
  other 0 0.00 %

Table of maximal quoting:

   Author   Percent 
1 info@boac.nl 77.38 %
2 pcsclite.pkoch@dfgh.net 53.62 %
3 Tom.Arnautovic@neardesk.com 36.24 %
4 moshman@gmail.com 32.81 %
5 morgner@informatik.hu-berlin.de 24.95 %
6 bill.c.roberts@gmail.com 23.27 %
7 henrik@synth.no 22.74 %
8 nicksp@gmail.com 21.21 %
9 ignacio.casal@nice-software.com 19.96 %
10 helpcrypto@gmail.com 15.32 %
11 fdeybach@gmail.com 14.77 %
12 saper@saper.info 14.59 %
13 guy@linux-service.be 14.53 %
14 Jindrich.Mican@lgnexera.at 14.53 %
15 elbuffo166@gmail.com 14.16 %
16 fdimitriou@tmm-software.com 13.75 %
17 jhutz@cmu.edu 13.59 %
18 rickyepoderi@yahoo.es 13.02 %
19 marian.thieme@gmail.com 13.02 %
20 william.to@erg.com.hk 11.63 %
21 ludovic.rousseau@gmail.com 8.78 %
22 orzel@freehackers.org 7.46 %
23 Pcsclite-muscle =
7.00 %
24 bbsoo7@live.com 6.35 %
25 EHeck@intarsys.de 5.93 %
26 martin@martinpaljak.net 5.54 %
27 luc.mazardo@orange.com 3.68 %
28 crack.nyse@gmail.com 3.41 %
29 Herve.CODINA@celad.com 3.12 %
30 godfreyhkchung@gmail.com 1.01 %
  average 14.73 %

Graph showing number of messages written during hours of day:

msgs
2
|
0
|
0
|
0
|
0
|
0
|
0
|
2
|
3
|
2
|
10
|
6
|
8
|
10
|
13
|
13
|
9
|
8
|
10
|
4
|
6
|
7
|
3
|
4
|
hour
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Graph showing number of messages written during days of month:

msgs
2
|
3
|
7
|
4
|
4
|
3
|
5
|
5
|
3
|
5
|
4
|
3
|
4
|
1
|
0
|
1
|
2
|
10
|
3
|
3
|
3
|
3
|
3
|
10
|
9
|
8
|
3
|
3
|
3
|
0
|
3
|
day
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Graph showing number of messages written during days of week:

msgs
16
|
25
|
23
|
19
|
26
|
6
|
5
|

Mon Tue Wed Thu Fri Sat Sun

Maximal quoting:

Author : guy@linux-service.be
Subject : [Pcsclite-muscle] debian 8 pcscd

Date : Wed, 22 Jul 2015 12:18:13 +0200

Quote ratio: 77.62% / 4540 bytes

Longest message:

Author : Tom.Arnautovic@neardesk.com
Subject : [Pcsclite-muscle] Card Reader Issue
Date : Mon, 18 May 2015 13:46:56 +0000
Size : 72421 bytes

Most successful subject:

Subject : [Pcsclite-muscle] Absence du bureau / Out of the office
No. of msgs: 13
Total size : 130236 bytes

Final summary:

Total number of messages: 120
Total number of different authors: 33
Total number of different subjects: 51
Total size of messages (w/o headers): 1083656 bytes
Average size of a message: 9030 bytes


Input file last updated: Sun Jan 3 10:18:30 2016
Generated by MailListStat v1.3

Happy new year 2016

Dear readers,

I wish you a happy new year for 2016.

In 2015 I published 51 articles on this blog. I do plan to continue writing about my smart card and Free Software activities in 2016.

Articles most read in 2015

Top 10 of all the blog articles:
Title #
Blog homepage 1
OS X Yosemite and smart cards status 2
PCSC sample in C# 3
PCSC sample in C 4
PC/SC sample in different languages 5
PCSC sample in Java 6
PCSC sample in Python 7
OS X Yosemite bug: SCardTransmit returns SCARD_W_UNPOWERED_CARD 8
PCSC sample in JavaScript (Node.js) 9
pcsc-lite upgrade and Ubuntu special configuration 10

PC/SC sample articles have success.

Most read Articles from 2015

Top 5 of the articles written in 2015:
Title #
OS X Yosemite bug: SCardTransmit returns SCARD_W_UNPOWERED_CARD 8
OS X Yosemite and smart cards status 2
PCSC sample in C# 3
PCSC sample in C 4
PC/SC sample in different languages 5
PCSC sample in Java 6
PCSC sample in Python 7
OS X Yosemite bug: SCardTransmit returns SCARD_W_UNPOWERED_CARD 8
PCSC sample in JavaScript (Node.js) 9
pcsc-lite upgrade and Ubuntu special configuration 10

Mac OS X articles have success. Don't worry, I do plan to continue writing about Mac OS X and smart cards.

Conclusion

If you have ideas of subjects you are interested in, or subjects you work on and you would like to get more visibility just tell me.

Apple PC/SC: blog articles about missing features

You may have noticed that I wrote 3 blog articles about missing features in the PC/SC layer from Apple.

  1. SCardGetStatusChange() and number of card events
  2. SCardGetStatusChange() and "\\?PnP?\Notification"
  3. add support of TAG_IFD_POLLING_THREAD_WITH_TIMEOUT

This is because Apple replaced pcsc-lite by something else in Yosemite (10.10) and improved it in El Capitan (10.11). I imagine that Apple is still working on this software and it is the good time to propose to Apple to implement features that are present in PC/SC on GNU/Linux and Windows but not (yet) on Mac OS X.

If you think these features are useful you should open bug reports at https://bugreport.apple.com. This will indicate that a feature is important for many users, and not just me. If more users create a bug report then priority for Apple to do something will be higher.

Of course, I would be happy to help Apple implement the missing features.

OS X El Capitan missing feature: add support of TAG_IFD_POLLING_THREAD_WITH_TIMEOUT

This is part of the series: "OS X El Capitan and smart cards: known bugs".

This is not a bug since this feature was never present in any PC/SC from Apple.

com.apple.ifdreader.slotd does not support TAG_IFD_POLLING_THREAD_WITH_TIMEOUT  and friends

The equivalent of pcscd on Mac OS X since Yosemite (10.10) is com.apple.ifdreader.slotd. See "OS X Yosemite and smart cards status". This process is in charge of loading the smart card reader driver. The API between pcscd or com.apple.ifdreader.slotd and the driver is defined in IFDHandler API.

The IFDHandler API evolved during the development of pcsc-lite and the CCID driver to support new features. Apple forked pcsc-lite in 2002 (see "Evolution of Apple pcsc-lite (from Jaguar to Mavericks)") and never merged back the changes I made in pcsc-lite and the IFDHandler API since that time.

Card status polling

In the early versions of pcsc-lite (when the smart card readers where using a RS 232 serial port because USB was not invented yet) the card state (card present or card absent) was checked using a regular polling (every 200 ms) of the reader. Every 200 ms a command is sent to the reader to know if a card is present or not.

The problem is that pcscd is then continuously running (and pcscd was reported by the powertop tool as one of the processes that prevent the CPU to sleep and consume less power)

Another problem is that you have to wait up to 200 ms to detect that a card has been inserted or removed in a reader.

Polling replaced

The CCID specification provides a way to indicate that a card event occurred. This mechanism uses an USB interrupt end point. See "New CCID 1.4.0 and card movement notification mechanism" for more details.

The new mechanism, introduced in the pcsc-lite and the CCID driver 2010, allows to let libusb-1.0 notify the driver that a card event occurred. The change was introduced in the CCID driver version 1.4.0 (with the update from libusb-0.1 to libusb-1.0) and in pcsc-lite 1.6.2 released at the same time.

The mechanism uses the IFDHandler function IFDHGetCapabilities to request the driver about three features:

This allows pcscd to delegate to the driver the cart event management. pcscd will call a function in the driver that will block until a card event occurs or the timeout expires.

Benefits to implement it

If such a mechanism is implemented by Apple in com.apple.ifdreader.slotd we could have, at least, three benefits.
  1. better reactivity when a smart card is inserted (or removed)
  2. lower CPU power consumption
  3. far less log messages when you debug a smart card driver (mostly useful to smart card reader driver developers ☺)

See also

Apple bug report #24009313 "PC/SC: com.apple.ifdreader.slotd does not support TAG_IFD_POLLING_THREAD_WITH_TIMEOUT and friends"

Closed by Apple on 19th January 2016 as a duplicate of 17534485.

Sample code

I do not provide code sample. It is an internal implementation issue with no impact on the PC/SC API.

Known workaround

None known. It is not an PC/SC API issue.

Remove and/or customize PC/SC reader names

The need

In some cases you need to control the smart card reader names reported by PC/SC.

For real examples see some requests sent on the Pcsclite-muscle mailing list: "Possibility to disable Reader Interface?", "Deny card access for one application" and "Dynamically disable/enable specific card reader".

Ignore some readers

For example imagine you have a laptop with 2 integrated smart card readers:
  • Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD)
  • Broadcom Corp 5880 [Contactless SmartCard] (0123456789ABCD)
One reader is contactless but you do not use it. The other is a contact reader and should be the only one used but the users of the laptop.
To ease the life of the users you do not want them to have to select the contact reader each time an application has to use a reader and ask the user to select one.

Since the readers are integrated into the laptop you can't easily unplug the reader you don't want to use. You need a solution to ignore unwanted readers at the PC/SC level.

Extend reader names

In this use case you use a remote desktop solution (RDP) to access a Windows server from your GNU/Linux laptop. Your company has equipped users with the same laptop model. So at the PC/SC level all the readers have the same name and this PC/SC name is forwarded to Windows through RDP.

Now imagine a bogus application on the Windows server (not too hard to imagine a bogus application on Windows ☺) that uses the PC/SC reader name to identify a user. Since every user is using the same laptop model they will all have the same PC/SC reader name in Windows. And the bogus Windows application is broken ☹ and can't be used.

The proposed solution

To enable these two features you need to configure pcsc-lite with --enable-filter.

Ignore some readers

If the environment variable PCSCLITE_FILTER_IGNORE_READER_NAMES is defined then it contains a list of patterns separated by the character ":".
If a pattern is found in a PC/SC reader name then this reader is ignored and will not be reported by SCardListReaders() or any other PC/SC calls.

In the example described above you would define PCSCLITE_FILTER_IGNORE_READER_NAMES as: "Contactless".

Extend reader names

To differentiate the PC/SC reader names one idea is to use the host name of the system. If the IT department is doing correctly his job every laptop should have a different host name.

If the environment variable PCSCLITE_FILTER_EXTEND_READER_NAMES is defined then it contains a string that will be added at the end of the PC/SC reader names.
The computer host name is available in the variable $HOSTNAME. If you want to have a space character between the PC/SC reader name and host name you define PCSCLITE_FILTER_EXTEND_READER_NAMES as:
" $HOSTNAME".

Setup

The Debian init script for pcscd contains:

NAME=pcscd
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

You then just have to create a file /etc/default/pcscd containing:
PCSCLITE_FILTER_IGNORE_READER_NAMES="Contactless"
PCSCLITE_FILTER_EXTEND_READER_NAMES=" $HOSTNAME"
And you are good to go.

GNU/Linux systems using systemd will need a different configuration. The systemd configuration is left as an exercise for the reader.

Conclusion

These new features will be provided in the next version of pcsc-lite.

If you have another special feature request for pcsc-lite, please do not hesitate to contact me.

Thanks

Thanks to Sparkasse Pforzheim Calw for the patch.

OS X El Capitan missing feature: SCardGetStatusChange() and "\\?PnP?\Notification"

This is part of the series: "OS X El Capitan and smart cards: known bugs".

SCardGetStatusChange() does not support "\\?PnP?\Notification"

SCardGetStatusChange() does not support the special reader name "\\?PnP?\Notification".

This is not a bug since this feature was never present in any PC/SC from Apple.

From the Doxygen documentation of pcsc-lite:
To wait for a reader event (reader added or removed) you may use the special reader name "\\?PnP?\Notification".
If a reader event occurs the state of this reader will change and the bit SCARD_STATE_CHANGED will be set.
With this feature it is possible to detect that a smart card reader has been added or removed to the system without polling with calls to SCardListReaders() in a loop.

This is used by my tools pcsc_scan from the pcsc-tools package.

See also

Apple bug report #23966225 "PC/SC SCardGetStatusChange() and "\\?PnP?\Notification""

Sample code

#include <stdio.h>
#ifdef __APPLE__
#include <PCSC/winscard.h>
#include <PCSC/wintypes.h>
#else
#include <winscard.h>
#endif

int main(void)
{
    SCARDCONTEXT hContext;
    LPSTR mszReaders;
    DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL,
        &hContext);
    if (err != SCARD_S_SUCCESS)
    {
        printf("ScardEstablishedContext: 0x%08x\n",err);
        return -1;
    }

    SCARD_READERSTATE rgReaderStates[1];
    rgReaderStates[0].szReader = "\\\\?PnP?\\Notification";
    rgReaderStates[0].dwCurrentState = SCARD_STATE_UNAWARE;
    rgReaderStates[0].dwEventState = SCARD_STATE_UNKNOWN;

    err = SCardGetStatusChange(hContext, 10, rgReaderStates, 1);
    printf("SCardGetStatusChange: %s (0x%08X)\n", pcsc_stringify_error(err),
        err);
    printf("dwEventState: %X\n", rgReaderStates[0].dwEventState);

    if (rgReaderStates[0].dwEventState & SCARD_STATE_UNKNOWN)
        printf("\\\\?PnP?\\Notification is NOT supported\n");
    else
        printf("\\\\?PnP?\\Notification IS supported\n");

    SCardReleaseContext(hContext);

    return 0;
}

Result (on El Capitan)

$ CFLAGS="-framework PCSC" make main
cc -framework PCSC    main.c   -o main
$ ./main
SCardGetStatusChange: Command successful. (0x00000000)
dwEventState: 6
\\?PnP?\Notification is NOT supported
The returned value for dwEventState is 6 and correspond to SCARD_STATE_CHANGED (2) + SCARD_STATE_UNKNOWN (4). PC/SC indicates that the reader "\\?PnP?\Notification" is unknown.

Note that SCardGetStatusChange() returns SCARD_S_SUCCESS and also waited for the indicated time, here 10 ms but you can increase the value to make the test more explicit.
The command should have returned immediately (or have returned SCARD_E_TIMEOUT). Yes, it is a bug in the PC/SC layer.

Expected result (on Debian)

$ CFLAGS=`pkg-config --cflags libpcsclite` LDFLAGS=`pkg-config --libs libpcsclite` make main
cc -pthread -I/usr/include/PCSC    -lpcsclite    main.c   -o main
$ ./main
SCardGetStatusChange: Command timeout. (0x8010000A)
dwEventState: 0
\\?PnP?\Notification IS supported
Here the command returns after the delay has expired because no reader has been connected or removed. The returned value is SCARD_E_TIMEOUT.
If a reader is connected or removed during the delay (here 10 ms) the command would have indicated SCARD_STATE_CHANGED for this reader.

Known workaround

None known.
Maybe Apple will add support of "\\?PnP?\Notification" one day.

OS X El Capitan missing feature: SCardGetStatusChange() and number of card events

This is part of the series: "OS X El Capitan and smart cards: known bugs".

SCardGetStatusChange() and number of card events

SCardGetStatusChange() does not return the number of card events in the upper word of dwEventState.

This is not a bug since I don't think this feature was every present in the PC/SC from Apple. It is a feature request and not a bug report.

From the Doxygen documentation of pcsc-lite:
dwEventState also contains a number of events in the upper 16 bits (dwEventState & 0xFFFF0000). This number of events is incremented for each card insertion or removal in the specified reader. This can be used to detect a card removal/insertion between two calls to SCardGetStatusChange().
This behaviour is also present in PC/SC on Windows.

It is the only way to know that the card has been removed from a reader and inserted again while no call to SCardGetStatusChange() was running. Potentially the inserted card is not the same as the removed card so the PC/SC application may have to build a new applicative context for the new card.

See also

Apple bug report #23937633 "PC/SC SCardGetStatusChange() and number of card events"

Sample code

Using the Python PC/SC wrapper PySCard to have a shorter code.

#! /usr/bin/env python

from smartcard.scard import *
from smartcard.pcsc.PCSCExceptions import *


def parseEventState(eventstate):
    stateList = list()
    states = {SCARD_STATE_IGNORE: "Ignore",
              SCARD_STATE_CHANGED: "Changed",
              SCARD_STATE_UNKNOWN: "Unknown",
              SCARD_STATE_UNAVAILABLE: "Unavailable",
              SCARD_STATE_EMPTY: "Empty",
              SCARD_STATE_PRESENT: "Present",
              SCARD_STATE_ATRMATCH: "ATR match",
              SCARD_STATE_EXCLUSIVE: "Exclusive",
              SCARD_STATE_INUSE: "In use",
              SCARD_STATE_MUTE: "Mute"}
    for state in states:
        if eventstate & state:
            stateList.append(states[state])
    return stateList

hresult, hcontext = SCardEstablishContext(SCARD_SCOPE_USER)
if hresult != SCARD_S_SUCCESS:
    raise EstablishContextException(hresult)

hresult, readers = SCardListReaders(hcontext, [])
if hresult != SCARD_S_SUCCESS:
    raise ListReadersException(hresult)
print 'PC/SC Readers:', readers

readerstates = {}
for reader in readers:
    readerstates[reader] = (reader, SCARD_STATE_UNAWARE)
hresult, newstates = SCardGetStatusChange(hcontext, 0, readerstates.values())
if hresult != SCARD_S_SUCCESS:
    raise BaseSCardException(hresult)
print newstates
for readerState in newstates:
    readername, eventstate, atr = readerState
    readerstates[readername] = (readername, eventstate)

print "Move the smart card"

ok = True
while ok:
    try:
        hresult, newstates = SCardGetStatusChange(hcontext, INFINITE, newstates)
        if hresult != SCARD_S_SUCCESS and hresult != SCARD_E_TIMEOUT:
            raise BaseSCardException(hresult)
    except KeyboardInterrupt:
        ok = False
    for readerState in newstates:
        readername, eventstate, atr = readerState
        states = parseEventState(eventstate)
        print states, hex(eventstate)

hresult = SCardReleaseContext(hcontext)
print "SCardReleaseContext()", SCardGetErrorMessage(hresult)
if hresult != SCARD_S_SUCCESS:
    raise ReleaseContextException(hresult)

Result (on El Capitan)

$ ./SCardGetStatusChange.py
PC/SC Readers: ['Gemalto PC Twin Reader']
[('Gemalto PC Twin Reader', 18, [])]
Move the smart card
['Changed', 'Present'] 0x22
['Empty', 'Changed'] 0x12
['Changed', 'Present'] 0x22
['Empty', 'Changed'] 0x12
^C['Empty', 'Changed'] 0x12
SCardReleaseContext() Command successful.

For the tests I insert and remove the card 2 times.

Then press Control-C and insert the card to quit the program.

Expected result (on Debian)

$ ./SCardGetStatusChange.py 
PC/SC Readers: ['Gemalto PC Twin Reader 00 00']
[('Gemalto PC Twin Reader 00 00', 18, [])]
Move the smart card
['Changed', 'Present'] 0x10022
['Empty', 'Changed'] 0x20012
['Changed', 'Present'] 0x30022
['Empty', 'Changed'] 0x40012
^C['Empty', 'Changed'] 0x40012
SCardReleaseContext() Command successful.

The change is the value eventstate displayed (in hexadecimal).

On Debian the high word (upper 16 bits) takes the values 1, 2, 3 and 4.

If the value change from 0x10022 to 0x30022, the reader state is the same (SCARD_STATE_CHANGED and SCARD_STATE_PRESENT) but you know that the card has been removed and inserted.

Known workaround

None known.

[Update 2022-08-31, after 7 years]

Apple just answered to my bug report, now called feedback.  The bug report #23937633 is now known as FB7531166. Apple answer is (I have it in French in my Feedback Assistant application. Surprising!):

"Thank you for your review and patience. We apologize for the late response. We do not intend to treat this report as an enhancement.

Indeed, adding new features to the existing PC/SC interface is not on the agenda. However, we will consider this suggestion in case our plans change."

Apple is reviewing (old) PC/SC issues. Nice to know.
But do not plan to add new features.

OS X El Capitan bug: SCardBeginTransaction() returns different error codes than on GNU/Linux and Windows

This is part of the series: "OS X El Capitan and smart cards: known bugs".

SCardBeginTransaction() returns different error codes than on GNU/Linux and Windows

I found 2 cases in which SCardBeginTransaction() on El Capitan returns error codes that are different than on GNU/Linux and Windows.

SCardBeginTransaction() returns SCARD_W_RESET_CARD after a card change

On El Capitan SCardBeginTransaction() returns SCARD_W_RESET_CARD if the card has been removed and inserted again in the reader.

On GNU/Linux and Windows SCardBeginTransaction() returns SCARD_W_REMOVED_CARD instead.

SCardBeginTransaction() returns SCARD_W_UNPOWERED_CARD after a card is unpowered

The same function SCardBeginTransaction() returns SCARD_W_UNPOWERED_CARD on Mac OS X El Capitan if the card has been powered off by another application.

On GNU/Linux and Windows SCardBeginTransaction() returns SCARD_W_RESET_CARD instead.

See also

Apple bug report #23900844 "PC/SC SCardBeginTransaction() returns different error codes than on GNU/Linux and Windows"

Sample code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#ifdef __APPLE__
#include <PCSC/winscard.h>
#include <PCSC/wintypes.h>
#else
#include <winscard.h>
#endif

#define pcsc_error(fct) printf(fct ": %s 0x%08lX\n", pcsc_stringify_error(err), (long)err)

int main(void)
{
 LPSTR mszReaders;
 DWORD err, cchReaders = 0;
 SCARDCONTEXT hContext = 0;
 SCARDHANDLE hCard = 0;

 err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
 if (err != SCARD_S_SUCCESS) {
  pcsc_error("ScardEstablishedContext");
  return -1;
 }

 err = SCardListReaders(hContext, NULL, NULL, &cchReaders);
 if (err != 0) {
  pcsc_error("ScardListReaders");
  return -1;
 }
 mszReaders = calloc(cchReaders, sizeof(char));
 if (!mszReaders) {
  printf("calloc\n");
  return -1;
 }
 err = SCardListReaders(hContext,NULL, mszReaders, &cchReaders);
 if (err != SCARD_S_SUCCESS) {
  pcsc_error("ScardListReaders");
  return -1;
 }

 printf("Using reader: %s\n", mszReaders);

 DWORD dwActiveProtocol;
 err = SCardConnect(hContext, mszReaders, SCARD_SHARE_SHARED, SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1, &hCard, &dwActiveProtocol);
    if (err != SCARD_S_SUCCESS) {
        pcsc_error("SCardConnect");
        return 0;
    }

 printf("Remove and insert the card. Then press enter\n");
 getchar();

 err = SCardBeginTransaction(hCard);
 if (err != SCARD_S_SUCCESS)
  pcsc_error("SCardBeginTransaction");

 err = SCardDisconnect(hCard, SCARD_LEAVE_CARD);
 if (err != SCARD_S_SUCCESS)
  pcsc_error("SCardDisconnect");

 SCardReleaseContext(hContext);

 return 0;
}

Reset program

Using the Python PC/SC wrapper PySCard to have a shorter code.

#! /usr/bin/env python

from smartcard.System import readers
from smartcard.scard import SCARD_UNPOWER_CARD, SCARD_RESET_CARD

reader = readers()[0]
print "Using:", reader

connection = reader.createConnection()
#connection.connect(disposition=SCARD_RESET_CARD)
connection.connect(disposition=SCARD_UNPOWER_CARD)

If you modify the reset program to use disposition=SCARD_RESET_CARD then SCardBeginTransaction() will return SCARD_W_RESET_CARD as is also the case on GNU/Linux and Windows.

Result (on El Capitan)

$ CFLAGS="-framework PCSC" make main
cc -framework PCSC    main.c   -o main

$ ./main
Using reader: Gemalto PC Twin Reader
Remove and insert the card. Then press enter

SCardBeginTransaction: Card was reset. 0x80100068

In case of unpower (instead of card removal) by a second application:
$ ./main
Using reader: Gemalto PC Twin Reader
Remove and insert the card. Then press enter

SCardBeginTransaction: Card is unpowered. 0x80100067

Expected result (on Debian)

$ CFLAGS=`pkg-config --cflags libpcsclite` LDFLAGS=`pkg-config --libs libpcsclite` make main
cc -pthread -I/usr/include/PCSC    -lpcsclite    main.c   -o main

$ ./main
Using reader: Gemalto PC Twin Reader 00 00
Remove and insert the card. Then press enter

SCardBeginTransaction: Card was removed. 0x80100069

In case of unpower:
$ ./main
Using reader: Gemalto PC Twin Reader 00 00
Remove and insert the card. Then press enter

SCardBeginTransaction: Card was reset. 0x80100068

Known workaround

None known.

I have not checked the same code on Mavericks (OS X 10.9) to see if it is a regression or not.
I guess the behaviour changed in Yosemite with the rewrite of PC/SC (see OS X Yosemite and smart cards status)

OS X El Capitan and smart card source code

Apple released the source code of the open source components they use in El Capitan (OS X 10.11 released in September 2015). The components are available at OS X 10.11 Source.



As I did for Yosemite in "OS X Yosemite and smart card source code" I will document what I found.

The smart card related components are:

See "OS X El Capitan and smart cards status" for a general discussion of the changes in El Capitan.

General remark

Apple published the source code at the same time they published the 2nd minor version of El Capitan: 10.11.2. Maybe Apple wanted to fix the most serious bugs before publishing the source code. Or maybe they had not enough free time before today?

SecurityTokend

The version did not changed from 55108 in Yosemite to 55108 in El Capitan.

It is surprising to see a Tokend related component. CDSA (and then tokend) has been deprecated in 2011.

Maybe Apple forgot to remove this component?

SmartcardCCID

The version did not changed from 55008 in Yosemite to 55008 in El Capitan.

The CCID driver has not changed between Yosemite and El Capitan. This is what I already found in "OS X El Capitan and smart cards status".

SmartCardServices

The version did not changed from 55111 in Yosemite to 55111 in El Capitan.

SmartCardServices is the component providing pcsc-lite. For Yosemite Apple rewrote the complete PC/SC stack and replaced pcsc-lite by something else. So this component is not used in El Capitan.

Maybe Apple forgot to remove this component?

Conclusion

No change at all since Yosemite in the Open Source components related to smart card.

The PC/SC layer changed. Apple fixed some bugs between Yosemite and El Capitan, see "OS X Yosemite and smart cards: known bugs". But Apple still does not provide the source code of this component.

Components not used any more in El Capitan are still provided in OS X 10.11 Source. It looks like Apple forgot to clean the list of the components used in El Capitan.