Important!

Blog moved to https://blog.apdu.fr/

I moved my blog from https://ludovicrousseau.blogspot.com/ to https://blog.apdu.fr/ . Why? I wanted to move away from Blogger (owne...

Wednesday, January 14, 2015

PCSC sample in Common Lisp

To continue the list of PC/SC wrapper initiated in 2010 with "PC/SC sample in different languages" I now present (or not) a PC/SC sample in Common Lisp.

YstokCard - smart card API

The project is hosted at http://lisp.ystok.ru/ycard/

" YstokCard is a portable Common Lisp library dealing with smart cards.
It allows a Lisp program to interact to integrated chip cards (ICC) and interface devices (IFD, card readers).

Memory cards can securely store relatively small amounts of data. Applications usually require certain conditions to be fulfilled before access to the data is possible, such as a PIN verification or authentication of the card.

Processor cards provide environment for the secure execution of programs. This makes smart cards good candidates for the entire security sector. Additionally, they have a well-established format and are convenient for manual use and handling.

YstokCard can be useful for programming both memory-based and file-based card applications. "

Basic features

  • Class hierarchy for cards and devices.
  • Conventions and macros for defining new card and device types.
  • ATR (Answer-To-Request) converting and analysis.
  • Calls to Smart Card Resource Manager (winscard.dll on Windows, libpcsclite.so on Linux).
  • Helpers like run-length-coding (RLC) etc.

Installation

I tried to install the wrapper on my Debian system with some documentation from the wrapper author himself: Dmitry Ivanov.

I failed to install the wrapper :-(. I am no more a Lisp user and I did not want to invest too much time in setting a working configuration.

Here is the documentation I got from Dmitry Ivanov in case you want to try by yourself:
The wrapper will not work with CLISP but only with:

Build/install means compile and load into a running Lisp system. The
procedure is not a simple "apt-get" call but consists of the manual
operations.

  1. Download zip/tgz bundles for all the dependencies.
  2. Extract all the files.
  3. Load ASDF package manager into the running lisp image by means of
  4. Load all the unzipped ASD-files, i.e. project files, e.g.
    (load "ystok-ffc.asd")
    (load "ystok-library.asd")
    (load "ystokcard.asd")
  5. Evaluate
    (asdf:operate 'asdf:load-op 'ystokcard).

Source code

Since I failed to install the Common Lisp wrapper I could not really write the sample code and test it.

Writing the sample source code is then left as an exercise to the reader :-)

Conclusion

I am sorry I can't really help you on this Common Lisp PC/SC wrapper.

If you are a Common Lisp user I imagine you will succeed in installing the wrapper correctly and using it for your project.

Even if I failed to install it myself I wanted to let you know that a Common Lisp wrapper exist for PC/SC.

Sunday, January 11, 2015

PCSC sample in PHP5

In PC/SC sample in different languages I "promised" to give the implementation of the same sample program in many different programming languages.

SCardSCR

In a previous article "PCSC sample in PHP" I wrote about SCardSCR.

SCardSCR is a project for Windows by Johann Dantant. The project web site is no more available because the domain name www.waazaa.org do not exist any more.

A user reported the problem to me and asked where the web site was available. I used a web search service to find were the project SCardSCR had been moved but I found a new PHP PC/SC wrapper instead.

PC/SC for PHP

PC/SC for PHP is the continuation of SCardSCR by Marco Schuster and Johannes Findeisen and is licensed under the PHP license:
This code is licensed under the terms of the PHP License version 3.01. PCSC-Lite is licensed in a way where it is possible to integrate it native in the PHP environment.

The project is hosted at http://hanez.org/pcsc-for-php.html and is also available at http://pecl.php.net/package/pcsc.

From the project About section:
This is the only extension for using PC/SC based smart cards with PHP. It is a wrapper to the wonderful and free project PCSC-Lite which is the middleware to access a smart card using SCard API (PC/SC). Since PCSC-Lite is compatible to the winscard API it should be possible to compile this extension using a Windows(R) operating system. Currently I only take focus on Linux environments.

Thanks are going to Johann Dantant! He provides a PC/SC extension for PHP since 2005 and I reused some of his code. He allowed me to relicense these parts under the terms of the PHP license so I could integrate PCSC-Lite natively into PHP. You find his work here.
Latest version is 0.3 released 2014-04-23

Since the project is hosted inside the PECL (PHP Extension Community Library) I guess/hope the "PC/SC for PHP" project will not disapear soon. From http://pecl.php.net/
PECL is a repository for PHP Extensions, providing a directory of all known extensions and hosting facilities for downloading and development of PHP extensions.

API

The API is documented at PC/SC for PHP - An extension for PHP using the winscard PC/SC API.

I note some missing PC/SC features:

Bug

I had to patch the code to add support of T=0 cards.
Index: pcsc.c
===================================================================
--- pcsc.c (révision 335717)
+++ pcsc.c (copie de travail)
@@ -590,7 +590,7 @@ PHP_FUNCTION(scard_list_readers)
    Return a handle to the card */
 PHP_FUNCTION(scard_connect)
 {
-  DWORD dwPreferredProtocol = SCARD_PROTOCOL_T1; 
+  DWORD dwPreferredProtocol = SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1; 
   DWORD dwCurrentProtocol;
   SCARDHANDLE hCard = 0;
   LONG rc = 0;

Installation

The installation on Debian is quiet easy.

I had to install the Debian packages:
  • php-pear to get the pecl(1) command
  • php5-dev to get the phpize(1) command (prepare a PHP extension for compiling)

$ sudo pecl install pcsc-alpha
downloading pcsc-0.3.tgz ...
Starting to download pcsc-0.3.tgz (8,939 bytes)
.....done: 8,939 bytes
4 source files, building
running: phpize
Configuring for:
PHP Api Version:         20131106
Zend Module Api No:      20131226
Zend Extension Api No:   220131226
building in /tmp/pear/temp/pear-build-rootMiAGhV/pcsc-0.3
running: /tmp/pear/temp/pcsc/configure
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed

[...]

libtool: finish: PATH="/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /tmp/pear/temp/pear-build-rootMiAGhV/pcsc-0.3/modules
----------------------------------------------------------------------
Libraries have been installed in:
   /tmp/pear/temp/pear-build-rootMiAGhV/pcsc-0.3/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

Build complete.
Don't forget to run 'make test'.

running: make INSTALL_ROOT="/tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3" install
Installing shared extensions:     /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/lib/php5/20131226/
Installing header files:          /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/include/php5/
running: find "/tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3" | xargs ls -dils
305074  4 drwxr-xr-x 3 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3
305078  4 drwxr-xr-x 4 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr
305082  4 drwxr-xr-x 3 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/include
305083  4 drwxr-xr-x 2 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/include/php5
276538  4 -rw-r--r-- 1 root root  1238 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/include/php5/php_pcsc.h
305079  4 drwxr-xr-x 3 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/lib
305080  4 drwxr-xr-x 3 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/lib/php5
305081  4 drwxr-xr-x 2 root root  4096 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/lib/php5/20131226
276304 60 -rwxr-xr-x 1 root root 60896 janv. 11 14:21 /tmp/pear/temp/pear-build-rootMiAGhV/install-pcsc-0.3/usr/lib/php5/20131226/pcsc.so

Build process completed successfully
Installing '/usr/lib/php5/20131226/pcsc.so'
Installing '/usr/include/php5/php_pcsc.h'
install ok: channel://pecl.php.net/pcsc-0.3
configuration option "php_ini" is not set to php.ini location
You should add "extension=pcsc.so" to php.ini

I had to edit the file /etc/php5/cli/php.ini to change the enable_dl definition:
; Whether or not to enable the dl() function.  The dl() function
; does NOT work properly in multithreaded servers, such as IIS or Zeus,
; and is automatically disabled on them.
; http://php.net/enable-dl
;enable_dl = Off
enable_dl = On

Source code

<?php

if (!extension_loaded('pcsc')) {
  dl('pcsc.so');
}

# Get a PC/SC context
$context = scard_establish_context();
//var_dump($context);

# Get the reader list
$readers = scard_list_readers($context);
//var_dump($readers);

# Use the first reader
$reader = $readers[0];
echo "Using reader: ", $reader, "\n";

# Connect to the card
$connection = scard_connect($context, $reader);
//var_dump($connection);

# Select Applet APDU
$CMD = "00A404000AA00000006203010C0601";
$res = scard_transmit($connection, $CMD);
var_dump($res);

# test APDU
$CMD = "00000000";
$res = scard_transmit($connection, $CMD);
var_dump($res);
echo pack("H*", $res), "\n";

# Release the PC/SC context
scard_release_context($context);

?>

Output

$ php sample.php 
Using reader: Gemalto PC Twin Reader 00 00
string(4) "9000"
string(28) "48656C6C6F20776F726C64219000"
Hello world!�

Conclusion

I have only tested the wrapper using the command line php5 program. I guess the wrapper should also be available from a PHP script in a HTML page hosted by a web server. In that case the PC/SC commands are executed on the server. I don't know what it can be used for. In general you want to use the smart card on the client side.

Happy hacking with this PHP PC/SC wrapper.

Tuesday, January 6, 2015

OS X Yosemite bug: T=0 is used instead of T=1 on dual protocol cards

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

SCardConnect(..., SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1, ...)

SCardConnect() has changed its preferred protocol on Yosemite.

If a smart card can do both protocols T=0 and T=1 it is possible to let SCardConnect() select the active protocol. T=1 has some advantages over T=0 (transparent support of extended APDU for example) so it is a good idea for a PC/SC layer to prefer T=1 over T=0.

On Mavericks (Mac OS X 10.9) the T=1 protocol was preferred over T=0. On Yosemite this has changed and T=0 is preferred now.

It is not really a bug since by using SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1 the application explicitly let the PC/SC layer to select the protocol. But it is a change compared to the previous OS X version and can be considered a regression.

I guess the behaviour change is due to the major rewrite of the PC/SC layer in Yosemite. See "OS X Yosemite and smart cards status".

ATR parsing

You can use my online ATR (Answer To Reset) parsing tool at Smart card ATR parsing. For my tests I use a smart card with the ATR: 3B D6 18 00 80 B1 80 6D 1F 03 80 51 00 61 10 30 9E. You can see the ATR parsing results at http://smartcard-atr.appspot.com/parse?ATR=3BD6180080B1806D1F038051006110309E.

In the case of my smart card you can see from the parsing results that both protocols are supported:
[...]
TD(1) = 0x80 Y(i+1) = b1000, Protocol T=0
----
TD(2) = 0xB1 Y(i+1) = b1011, Protocol T=1
[...]


See also

Apple bug report #19384330 "PC/SC SCardConnect(): T=0 is used instead of T=1 on dual protocol cards". Closed by Apple, 9th January 2015, as a duplicated of #18567029.

Sample code

The sample code does:
  1. connect using SCardConnect(..., SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1, ...)
  2. display the protocol selected by SCardConnect()
  3. display the ATR so you can feed it to Smart card ATR parsing

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

int main(int argc, const char * argv[]) {
    SCARDCONTEXT hContext;
    LPSTR mszReaders;
    DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
    if (err != SCARD_S_SUCCESS) {
        printf("ScardEstablishedContext : %08x\n",err);
  return -1;
    }

 DWORD cchReaders = 0;
 err = SCardListReaders(hContext, "SCard$AllReaders", NULL, &cchReaders);
 if (err != 0) {
  printf("ScardListReaders : %08x\n",err);
  return -1;
 }
 mszReaders = calloc(cchReaders, sizeof(char));
 if (!mszReaders) {
  printf("calloc\n");
  return -1;
 }
 err = SCardListReaders(hContext,"SCard$AllReaders", mszReaders, &cchReaders);
 if (err != SCARD_S_SUCCESS) {
  printf("ScardListReaders : %08x\n",err);
  return -1;
 }

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

 SCARDHANDLE hCard;
 DWORD dwActiveProtocol;
 err = SCardConnect(hContext, mszReaders, SCARD_SHARE_SHARED, SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1, &hCard, &dwActiveProtocol);
 if (err != SCARD_S_SUCCESS) {
  printf("SCardConnect: 0x%08x\n",err);
  return -1;
 }

 printf("Prococol: ");
 switch(dwActiveProtocol)
 {
  case SCARD_PROTOCOL_T0:
   printf("SCARD_PROTOCOL_T0\n");
   break;
  case SCARD_PROTOCOL_T1:
   printf("SCARD_PROTOCOL_T1\n");
   break;
  default:
   printf("unknown\n");
 }

 char name[100];
 DWORD len = sizeof name;
 DWORD dwState, dwProtocol;
 unsigned char atr[MAX_ATR_SIZE];
 DWORD atr_len = sizeof atr;
 err = SCardStatus(hCard, name, &len, &dwState, &dwProtocol, atr, &atr_len);
 if (err != SCARD_S_SUCCESS) {
  printf("SCardStatus: 0x%08x\n",err);
  return -1;
 }
 printf("ATR: ");
 for (int i=0; i<atr_len; i++)
  printf("%02X ", atr[i]);
 printf("\n");

 SCardDisconnect(hCard, SCARD_LEAVE_CARD);
 SCardReleaseContext(hContext);

    return 0;
}

Result (on Yosemite)

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

$ ./main
Reader : Gemalto PC Twin Reader
Prococol: SCARD_PROTOCOL_T0
ATR: 3B D6 18 00 80 B1 80 6D 1F 03 80 51 00 61 10 30 9E

T=0 (SCARD_PROTOCOL_T0) has been selected.

Expected result (on Mavericks)

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

$ ./main
Reader : Gemplus GemPC Twin 00 00
Prococol: SCARD_PROTOCOL_T1
ATR: 3B D6 18 00 80 B1 80 6D 1F 03 80 51 00 61 10 30 9E

T=1 (SCARD_PROTOCOL_T1) has been selected.

Known workaround

Force the use of T=1 only on dual protocol cards it you really want to use T=1 instead of T=0.

You have to parse the ATR to know if the card supports T=0 and/or T=1. This is not an easy task. Maybe it is simpler to first call SCardConnect(..., SCARD_PROTOCOL_T1, ...) and if that fails call SCardConnect(..., SCARD_PROTOCOL_T0, ...).

Note that in case of protocol not supported the error returned is SCARD_E_NOT_TRANSACTED on Yosemite but SCARD_E_PROTO_MISMATCH on Mavericks. See OS X Yosemite bug: SCARD_E_PROTO_MISMATCH not returned.

Update

This bug is now fixed in Mac OS X Yosemite 10.10.2.

OS X Yosemite bug: SCARD_E_PROTO_MISMATCH not returned

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

SCARD_E_PROTO_MISMATCH not returned by SCardConnect()

In case of card communication protocol not supported, SCardConnect() returns the error SCARD_E_NOT_TRANSACTED on Yosemite but the error code is SCARD_E_PROTO_MISMATCH on Mavericks (and also on pcsc-lite on GNU/Linux).

This is a regression from Mavericks. I guess the same problem is also present with SCardReconnect().

SCARD_E_NOT_TRANSACTED should not be the error code for any error. SCARD_E_PROTO_MISMATCH is the correct error code to return in this case.

See also

Apple bug report #19384251 "PC/SC: SCARD_E_PROTO_MISMATCH not returned by SCardConnect()". Closed by Apple, 9th January 2015, as a duplicated of #18689292.

Sample code

The sample code uses SCardConnect(.., SCARD_PROTOCOL_T1, ..) to force the use of T=1. If you insert a T=0 only card you will get an error code from SCardConnect().

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

int main(int argc, const char * argv[]) {
    SCARDCONTEXT hContext;
    LPSTR mszReaders;
    DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
    if (err != SCARD_S_SUCCESS) {
        printf("ScardEstablishedContext : %08x\n",err);
  return -1;
    }

 DWORD cchReaders = 0;
 err = SCardListReaders(hContext, "SCard$AllReaders", NULL, &cchReaders);
 if (err != 0) {
  printf("ScardListReaders : %08x\n",err);
  return -1;
 }
 mszReaders = calloc(cchReaders, sizeof(char));
 if (!mszReaders) {
  printf("calloc\n");
  return -1;
 }
 err = SCardListReaders(hContext,"SCard$AllReaders", mszReaders, &cchReaders);
 if (err != SCARD_S_SUCCESS) {
  printf("ScardListReaders : %08x\n",err);
  return -1;
 }

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

 SCARDHANDLE hCard;
 DWORD dwActiveProtocol;
 err = SCardConnect(hContext, mszReaders, SCARD_SHARE_SHARED, SCARD_PROTOCOL_T1, &hCard, &dwActiveProtocol);
 if (err != SCARD_S_SUCCESS) {
  printf("SCardConnect: 0x%08x\n",err);
  return -1;
 }

 SCardDisconnect(hCard, SCARD_LEAVE_CARD);
 SCardReleaseContext(hContext);

    return 0;
}

Result (on Yosemite)

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

$ ./main
Reader : Gemalto PC Twin Reader
SCardConnect: 0x80100016

0x80100016 is SCARD_E_NOT_TRANSACTED.

Expected result (on Mavericks)

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

$ ./main
Reader : Gemplus GemPC Twin 00 00
SCardConnect: 0x8010000f

0x8010000f is SCARD_E_PROTO_MISMATCH.

Known workaround

You should expect the error SCARD_E_NOT_TRANSACTED instead of SCARD_E_PROTO_MISMATCH on Yosemite.

On Yosemite it is no more possible to decide if SCARD_E_NOT_TRANSACTED is returned because the requested protocol is not supported or because another error has occurred.

Update

This bug is now fixed in Mac OS X Yosemite 10.10.2.

Monday, January 5, 2015

OS X Yosemite bug: PC/SC functions crash after a fork(2)

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

All (?) PC/SC functions

SCardxx() do not work on Yosemite if executed in a son process of the one that has executed SCardEstablishContext().

This happen if SCardEstablishContext() is exected and then the process is forked. The PC/SC functions used in the son using the hContext received by the SCardEstablishContext() in the parent process will crash.

I verified this behaviour only with SCardListReaders() and SCardConnect(). I would not be surprised if it is the case for all PC/SC functions (except SCardEstablishContext() of course).

Using a PC/SC context in a son process after a fork(2) may not be supported by the PC/SC API. The support of such a use case has changed in the official pcsc-lite. The current version (pcsc-lite 1.8.13) will support it but be sure to not use the PC/SC handle in the parent process if you want to use it in the son process (or you will have problems).
In the case of Yosemite the PC/SC function will even crash instead of returning an error code.

See also

Apple bug report #19374107 "PC/SC functions crash after a fork(2)".

"com.apple.pcsc Crashes in SCardDisconnect / transact / libdispatch / fork resource handling code" https://smartcardservices.macosforge.org/trac/ticket/141.

"OpenVPN Crashes in OpenSC pcsc_disconnect on OSX 10.10 Yosemite" https://github.com/OpenSC/OpenSC/issues/333.

Sample code

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

int main(int argc, const char * argv[]) {
 SCARDCONTEXT hContext;
 DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
 if (err != SCARD_S_SUCCESS) {
  printf("ScardEstablishedContext: 0x%08x\n",err);
  return -1;
 }

 pid_t pid = fork();
 printf("%s:%d %d\n", __FILE__, __LINE__, pid);
 if (0 == pid)
 {
  /* son process */
  printf("Before\n");
  DWORD cchReaders = 0;
  err = SCardListReaders(hContext, "SCard$AllReaders", NULL, &cchReaders);
  if (err != 0) {
   printf("ScardListReaders: 0x%08x\n",err);
   return -1;
  }
  printf("Has not crashed: %X\n", err);
 }
 else
 {
  /* give some time to the son */
  sleep(1);
 }

 SCardReleaseContext(hContext);

 return 0;
}


Result (on Yosemite)

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

$ ./main
main.c:19 8236
main.c:19 0
Before

I could not generate a crash dump or a backtrace using lldb.
You can see that the line "Has not crashed: xx" is NOT displayed. The function SCardListReaders() has crashed and has not returned.

I can reproduce the problem and generate a crash dump using the pcsc-lite unitary test SCard_fork.py. This is less easy to use since you have to install the PC/SC Python wrapper pyscard first.

The crash dump is then:
Process:               Python [8270]
Path:                  /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               2.7.6 (2.7.6)
Code Type:             X86-64 (Native)
Parent Process:        Python [8268]
Responsible:           Terminal [450]
User ID:               501

PlugIn Path:             /Library/Python/2.7/site-packages/smartcard/scard/_scard.so
PlugIn Identifier:       _scard.so
PlugIn Version:          ??? (0)

Date/Time:             2015-01-05 15:54:21.335 +0100
OS Version:            Mac OS X 10.10.1 (14B25)
Report Version:        11
Anonymous UUID:        7FE6A9DE-5002-1B38-88FE-227046540C73

Sleep/Wake UUID:       99799303-CF96-4849-9024-4B487D8B2393

Time Awake Since Boot: 7600 seconds
Time Since Wake:       3600 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000110

VM Regions Near 0x110:
--> 
    __TEXT                 000000010837b000-000000010837c000 [    4K] r-x/rwx SM=COW  /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libdispatch.dylib      0x00007fff8ddae5d2 _dispatch_queue_wakeup_with_qos_slow + 525
1   libdispatch.dylib      0x00007fff8ddae5f8 _dispatch_queue_wakeup_with_qos_slow + 563
2   libdispatch.dylib      0x00007fff8dda3cfc _dispatch_mach_msg_send + 1690
3   libdispatch.dylib      0x00007fff8dda35e4 dispatch_mach_send + 326
4   libxpc.dylib           0x00007fff887048b1 _xpc_connection_send_message_with_reply_f + 125
5   libxpc.dylib           0x00007fff887047c2 xpc_connection_send_message_with_reply_sync + 185
6   com.apple.pcsc         0x00000001086fec5b transact + 604
7   com.apple.pcsc         0x00000001086ffe73 SCardListReaders + 140
8   _scard.so              0x00000001086ec6a5 _wrap_SCardListReaders + 181 (scard_wrap.c:3401)
9   org.python.python      0x0000000108407180 PyEval_EvalFrameEx + 12778
10  org.python.python      0x0000000108403d62 PyEval_EvalCodeEx + 1413
11  org.python.python      0x000000010840a57d 0x108380000 + 566653
12  org.python.python      0x00000001084073e3 PyEval_EvalFrameEx + 13389
13  org.python.python      0x0000000108403d62 PyEval_EvalCodeEx + 1413
14  org.python.python      0x00000001084037d7 PyEval_EvalCode + 54
15  org.python.python      0x00000001084237bd 0x108380000 + 669629
16  org.python.python      0x0000000108423860 PyRun_FileExFlags + 133
17  org.python.python      0x00000001084233fd PyRun_SimpleFileExFlags + 769
18  org.python.python      0x0000000108434b23 Py_Main + 3051
19  libdyld.dylib          0x00007fff8ca555c9 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00007f97b2517a50  rcx: 0x0000000000000100  rdx: 0x0000000000000001
  rdi: 0x00007f97b244f620  rsi: 0x0000000000000001  rbp: 0x00007fff57883990  rsp: 0x00007fff57883960
   r8: 0x0000000000000006   r9: 0x00000000fffff000  r10: 0x00007fff7584b244  r11: 0x0000000000000206
  r12: 0x0000000000000001  r13: 0x00007f97b244f620  r14: 0x0000000000001000  r15: 0x00007fff76583bc0
  rip: 0x00007fff8ddae5d2  rfl: 0x0000000000010206  cr2: 0x0000000000000110
  
Logical CPU:     1
Error Code:      0x00000006
Trap Number:     14

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
main.c:19 2274
main.c:19 0
Before
Has not crashed: 0

Here the line "Has not crashed: 0" is displayed and SCardListReaders() returned SCARD_S_SUCCESS.

Known workaround

Do not share a PC/SC context between a father process and its sons. It is a dangerous use the of PC/SC API. In the case of Yosemite it will even make your application crash.

Update, 4 April 2015

A reader signals that the Mac OS X behaviour is normal according to fork(2) manpage.

CAVEATS
There are limits to what you can do in the child process. To be totally safe you should restrict yourself to only executing async-signal safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frameworks in the child process, you must exec. In this situation it is reasonable to exec yourself.

Mavericks

Maybe it is an expected behaviour. But it is a regression compared to Mavericks (Mac OS X 10.9).

On Mavericks the output is:
$ ./main
a.c:19 2297
a.c:19 0
Before
Has not crashed: 0

Update, 14 November 2015

Answer from Apple to my bug report:
Please know this is intended behavior. Please review the CAVEATS section in the fork() manpage.

To clarify: It is intended that the results are undefined & unsupported for using Darwin APIs beyond the POSIX standard in a forked child of a parent process that had also used Darwin APIs beyond the POSIX standard. In such cases we try to at least make the crash report contain a clear indication that the program attempted such unsupported behavior. In this case the crash doesn’t have any such indication; for that we apologize.

Sunday, January 4, 2015

OpenSC-devel mailing list statistics for 2014

Statistics for previous years 2011, 2012 and 2013 are available.

Evolution

The OpenSC-devel mailing list number of messages is stable compared to last year.

Year Total number of messages Progression
20113214
2012626-80 %
2013317-49 %
2014335+6 %

As last year, the top poster is Douglas E Engert. Now that he is retired he has even more time to post on the OpenSC mailing list :-). His progression is +41% of messages.

I moved from the 2nd position to the 10th position with -63% of messages.



Statistics from 7.1.2014 to 23.12.2014
for opensc-devel@lists.sourceforge.net



People who have written most messages:

  Author  Msg  Percent 
1deengert@gmail.com58 17.31 %
2andreas.schwier.ml@cardcontact.de25 7.46 %
3anders.rundgren.net@gmail.com21 6.27 %
4martin@martinpaljak.net19 5.67 %
5dwmw2@infradead.org18 5.37 %
6bill.c.roberts@gmail.com16 4.78 %
7morgner@informatik.hu-berlin.de16 4.78 %
8viktor.tarasov@gmail.com13 3.88 %
9roberto@resolutions.it13 3.88 %
10ludovic.rousseau@gmail.com12 3.58 %
11shaun.schutte@tis.bz.it9 2.69 %
12J.Witvliet@mindef.nl6 1.79 %
13ndk.clanbo@gmail.com5 1.49 %
14muzio.francesco@clear-elettronica.it5 1.49 %
15n.mavrogiannopoulos@gmail.com5 1.49 %
16helpcrypto@gmail.com5 1.49 %
17deengert@anl.gov4 1.19 %
18nsara_57@hotmail.com4 1.19 %
19lturek@enovacom.fr3 0.90 %
20munoz0raul@gmail.com3 0.90 %
21leonardo.schenkel@gmail.com3 0.90 %
22Erik.Schick@taskit.de3 0.90 %
23sanaullah82@gmail.com3 0.90 %
24dirkx@webweaving.org3 0.90 %
25tristan.timmermans@ubiqu.nl3 0.90 %
26nmav@gnutls.org3 0.90 %
27ribalkin@gmail.com2 0.60 %
28maxxer@ufficyo.com2 0.60 %
29erik.g.bostrom@gmail.com2 0.60 %
30ondrej.mikle@nic.cz2 0.60 %
 other4914.63 %

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

  Author  KBytes 
1wendlandphilip@gmail.com5357.8
2deengert@gmail.com 908.3
3bill.c.roberts@gmail.com 331.6
4andreas.schwier.ml@cardcontact.de 219.7
5dwmw2@infradead.org 141.2
6anders.rundgren.net@gmail.com 125.8
7martin@martinpaljak.net 110.6
8morgner@informatik.hu-berlin.de 104.2
9viktor.tarasov@gmail.com 99.5
10dirkx@webweaving.org 99.4
11roberto@resolutions.it 87.9
12ludovic.rousseau@gmail.com 72.9
13J.Witvliet@mindef.nl 67.6
14shaun.schutte@tis.bz.it 52.0
15eric@kuroneko.ca 47.5
16n.mavrogiannopoulos@gmail.com 46.2
17ndk.clanbo@gmail.com 39.4
18nmav@gnutls.org 37.4
19helpcrypto@gmail.com 36.4
20nsara_57@hotmail.com 34.5
21muzio.francesco@clear-elettronica.it 32.4
22tristan.timmermans@ubiqu.nl 27.2
23munoz0raul@gmail.com 24.1
24lturek@enovacom.fr 23.1
25deengert@anl.gov 22.8
26marjan.stankovic@gmail.com 22.3
27Erik.Schick@taskit.de 22.2
28alon.barlev@gmail.com 20.2
29jblaine@kickflop.net 17.6
30leonardo.schenkel@gmail.com 16.2

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

  Author  bytes 
1wendlandphilip@gmail.com2743179
2eric@kuroneko.ca48636
3dirkx@webweaving.org33930
4marjan.stankovic@gmail.com22835
5bill.c.roberts@gmail.com21224
6jblaine@kickflop.net18003
7deengert@gmail.com16035
8etienne.cordonnier@theobroma-systems.com13715
9nmav@gnutls.org12759
10J.Witvliet@mindef.nl11542
11pstew@chromium.org11174
12loniux.mail@gmail.com10495
13alon.barlev@gmail.com10358
14n.mavrogiannopoulos@gmail.com9467
15tristan.timmermans@ubiqu.nl9289
16andreas.schwier.ml@cardcontact.de8997
17nsara_57@hotmail.com8819
18thican@thican.net8533
19munoz0raul@gmail.com8214
20ndk.clanbo@gmail.com8066
21dwdopensc@drdykstra.us8040
22dwmw2@infradead.org8033
23Johannes.Becker@hrz.uni-giessen.de8014
24jaroslav.imrich@gmail.com7983
25lturek@enovacom.fr7877
26viktor.tarasov@gmail.com7839
27Erik.Schick@taskit.de7583
28vlastimil.pavicek@centrum.cz7541
29mmartynas@gmail.com7485
30helpcrypto@gmail.com7460

Table showing the most successful subjects:

  Subject  Msg  Percent 
1[Opensc-devel] OpenSC Internet Explorer
18 5.37 %
2[Opensc-devel] Repeated login issues with Yubikey NEO
11 3.28 %
3[Opensc-devel] CKR_ARGUMENTS_BAD
10 2.99 %
4[Opensc-devel] Why do PIV key and cert labels not match?
10 2.99 %
5[Opensc-devel] [OpenSC] openssl req -engine pkcs11 fails with
9 2.69 %
6[Opensc-devel] Safran Morpho YpsID S3
9 2.69 %
7[Opensc-devel] Jenkins
9 2.69 %
8[Opensc-devel] PINPAD quirks
7 2.09 %
9[Opensc-devel] ACOS5 smart cards support
6 1.79 %
10[Opensc-devel] Format of extracted ECC public keys
6 1.79 %
11[Opensc-devel] using MyEID without a PIN
6 1.79 %
12[Opensc-devel] PKCS#11 usability improvements
6 1.79 %
13[Opensc-devel] Minidriver still marked experimental
5 1.49 %
14[Opensc-devel] Adding support for AES General Auth
5 1.49 %
15[Opensc-devel] "fatal: could not initialize dst: crypto
5 1.49 %
16[Opensc-devel] Support of French Professional Health Card CPS3
4 1.19 %
17[Opensc-devel] reader & card that can sign files and accept
4 1.19 %
18[Opensc-devel] Problem with generating keys on SmartCard HSM
4 1.19 %
19[Opensc-devel] Request for object 5C017E in PIV
4 1.19 %
20[Opensc-devel] Smart Cards vs. TEEs
4 1.19 %
21[Opensc-devel] The TPM is dead, long live the TEE!
4 1.19 %
22[Opensc-devel] Is openct dead?
4 1.19 %
23[Opensc-devel] building 0.14
4 1.19 %
24[Opensc-devel] Discussion about OpenSC broken PKCS#11 compliance
4 1.19 %
25[Opensc-devel] Smartcard-HSM sleeping?
4 1.19 %
26[Opensc-devel] PKCS#11, ECC and OpenSSL
4 1.19 %
27[Opensc-devel] The RSA division joins Google's U2F
3 0.90 %
28[Opensc-devel] minidriver setup
3 0.90 %
29[Opensc-devel] Fixed ALL compiler warnings
3 0.90 %
30[Opensc-devel] PIV cards and Mobile Devices
3 0.90 %
 other15746.87 %

Most used email clients:

  Mailer  Msg  Percent 
1Mozilla/5.x171 51.04 %
2(unknown)111 33.13 %
3Evolution 3.12.8 (3.12.8-1.fc21)
13 3.88 %
4obfuscated
9 2.69 %
5Mutt6 1.79 %
6Evolution 3.12.7 (3.12.7-1.fc21)
6 1.79 %
7Apple Mail (2.1874)
3 0.90 %
8Apple Mail (2.1878.2)
2 0.60 %
9Apple Mail (2.1985.3)
2 0.60 %
10K-9 Mail for Android
2 0.60 %
11Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC33 (Linux)/8.0.6_GA_5922)
1 0.30 %
12Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC34 (Linux)/8.0.6_GA_5922)
1 0.30 %
13Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix)
1 0.30 %
14Centrum Email 5.3
1 0.30 %
15YahooMailWebService/0.8.185.657
1 0.30 %
16KMail1 0.30 %
17Apple Mail (2.1973.6)
1 0.30 %
18Microsoft Outlook 15.0
1 0.30 %
19Evolution 3.12.7-1
1 0.30 %
 other1 0.30 %

Table of maximal quoting:

  Author  Percent 
1ebr.ghasemi@gmail.com 62.29 %
2frederic.vandevelde@paradigmo.com 55.75 %
3florian.bruckner@3kraft.com 54.19 %
4opensc@secure-edge.com 46.42 %
5adam@digitalpirate.ca 45.28 %
6deengert@anl.gov 42.41 %
7Andrea.Cremaschi@midainformatica.it 39.68 %
8andre.tampubolon@ciptasrigatilestari.co.id 38.02 %
9marjan.stankovic@gmail.com 34.74 %
10muzio.francesco@clear-elettronica.it 30.15 %
11shaun.schutte@tis.bz.it 29.57 %
12lholzheid@bihl-wiedemann.de 29.36 %
13viktor.tarasov@gmail.com 27.86 %
14helpcrypto@gmail.com 26.97 %
15alexandre.aufrere@opentrust.com 25.92 %
16ndk.clanbo@gmail.com 22.41 %
17sanaullah82@gmail.com 22.28 %
18morgner@informatik.hu-berlin.de 21.03 %
19earl@baugh.org 20.37 %
20andreas.schwier.ml@cardcontact.de 19.39 %
21jaroslav.imrich@gmail.com 19.24 %
22J.Witvliet@mindef.nl 18.52 %
23ludovic.rousseau@gmail.com 17.92 %
24erik.g.bostrom@gmail.com 17.74 %
25tristan.timmermans@ubiqu.nl 15.72 %
26aivaraslaimikis@gmail.com 15.64 %
27lturek@enovacom.fr 14.32 %
28martin@martinpaljak.net 13.32 %
29n.mavrogiannopoulos@gmail.com 11.93 %
30dwmw2@infradead.org 11.08 %
 average 5.66 %

Graph showing number of messages written during hours of day:

msgs
5
|
4
|
0
|
0
|
2
|
3
|
4
|
10
|
24
|
17
|
21
|
30
|
16
|
20
|
21
|
24
|
27
|
30
|
12
|
15
|
17
|
14
|
8
|
9
|
hour
01234567891011121314151617181920212223

Warning: 2 message(s) not counted.


Graph showing number of messages written during days of month:

msgs
7
|
6
|
16
|
19
|
11
|
11
|
14
|
7
|
5
|
27
|
8
|
3
|
9
|
22
|
5
|
10
|
10
|
7
|
13
|
12
|
6
|
9
|
14
|
10
|
9
|
11
|
9
|
16
|
16
|
8
|
3
|
day
12345678910111213141516171819202122232425262728293031

Warning: 2 message(s) not counted.


Graph showing number of messages written during days of week:

msgs
69
|
49
|
57
|
69
|
53
|
11
|
25
|

MonTueWedThuFriSatSun

Warning: 2 message(s) not counted.


Maximal quoting:

Author : frederic.vandevelde@paradigmo.com
Subject : [Opensc-devel] using MyEID without a PIN

Date : Fri, 6 Jun 2014 14:32:24 +0200

Quote ratio: 70.50% / 20823 bytes

Longest message:

Author : wendlandphilip@gmail.com
Subject : [Opensc-devel] Format of extracted ECC public keys
Date : Thu, 25 Sep 2014 17:43:22 +0200
Size : 5481666 bytes

Most successful subject:

Subject : [Opensc-devel] OpenSC Internet Explorer
No. of msgs: 18
Total size : 145598 bytes

Final summary:

Total number of messages: 335
Total number of different authors: 70
Total number of different subjects: 138
Total size of messages (w/o headers): 9292267 bytes
Average size of a message: 27738 bytes


Input file last updated: Sun Jan 4 18:09:51 2015
Generated by MailListStat v1.3