From germano.massullo at gmail.com  Thu Apr  5 02:39:49 2018
From: germano.massullo at gmail.com (Germano Massullo)
Date: Thu, 5 Apr 2018 11:39:49 +0200
Subject: [Pcsclite-muscle] Firefox does not trigger pcsc start
Message-ID: <29928f39-931c-c529-f7f0-a5fdfc60b53e@gmail.com>

Good day.
I am working on bringing back Estonia Open ID software stack on Fedora
repository.
The main packages are:
qesteidutil [1] [2] utility for Estonia ID cards
qdigidoc [3] [4] utility for signing documents
firefox-pkcs11-loader [5] [6] helper script for Firefox that sets up the
browser for authentication with Estonian ID-card
chrome-token-signing [7] [8] Chrome and Firefox extension for signing on
the web using Estonian ID-card

pcscd service automatically starts when qesteidutil or qdigidoc are
opened by the user.
Instead pcscd service does not start when you use Firefox (Chrome is not
part of Fedora packages). So you have to manually start it with command
# systemctl start pcscd

Do you have any idea why there is this problem with Firefox?
Best regards

[1]: https://github.com/open-eid/qesteidutil
[2]: https://src.fedoraproject.org/rpms/qesteidutil
[3]: https://github.com/open-eid/qdigidoc
[4]: https://src.fedoraproject.org/rpms/qdigidoc
[5]: https://github.com/open-eid/firefox-pkcs11-loader
[6]: https://src.fedoraproject.org/rpms/firefox-pkcs11-loader
[7]: https://github.com/open-eid/chrome-token-signing
[8]: https://src.fedoraproject.org/rpms/webextension-token-signing





From ludovic.rousseau at gmail.com  Thu Apr  5 03:03:02 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Thu, 5 Apr 2018 12:03:02 +0200
Subject: [Pcsclite-muscle] Firefox does not trigger pcsc start
In-Reply-To: <29928f39-931c-c529-f7f0-a5fdfc60b53e@gmail.com>
References: <29928f39-931c-c529-f7f0-a5fdfc60b53e@gmail.com>
Message-ID: <CAGstE8AF4pq3_dwefu+i7Ay8bG9HWeOZPXzgVvRxMKJBrs2o3g@mail.gmail.com>

2018-04-05 11:39 GMT+02:00 Germano Massullo <germano.massullo at gmail.com>:
> Good day.

Hello,

> I am working on bringing back Estonia Open ID software stack on Fedora
> repository.
> The main packages are:
> qesteidutil [1] [2] utility for Estonia ID cards
> qdigidoc [3] [4] utility for signing documents
> firefox-pkcs11-loader [5] [6] helper script for Firefox that sets up the
> browser for authentication with Estonian ID-card
> chrome-token-signing [7] [8] Chrome and Firefox extension for signing on
> the web using Estonian ID-card
>
> pcscd service automatically starts when qesteidutil or qdigidoc are
> opened by the user.
> Instead pcscd service does not start when you use Firefox (Chrome is not
> part of Fedora packages). So you have to manually start it with command
> # systemctl start pcscd
>
> Do you have any idea why there is this problem with Firefox?

I guess the problem is not with Firefox itself but with the pkcs#11
library used in firefox.


>From your RedHat bug report
https://bugzilla.redhat.com/show_bug.cgi?id=1545027 it looks like an
issue with systemd activation.
Please debug with a simple tool like pcsc_scan.
Get it from http://ludovic.rousseau.free.fr/softwares/pcsc-tools/ or
use the redhat package.

Does pcsc_scan works in your configuration?

Bye

> Best regards
>
> [1]: https://github.com/open-eid/qesteidutil
> [2]: https://src.fedoraproject.org/rpms/qesteidutil
> [3]: https://github.com/open-eid/qdigidoc
> [4]: https://src.fedoraproject.org/rpms/qdigidoc
> [5]: https://github.com/open-eid/firefox-pkcs11-loader
> [6]: https://src.fedoraproject.org/rpms/firefox-pkcs11-loader
> [7]: https://github.com/open-eid/chrome-token-signing
> [8]: https://src.fedoraproject.org/rpms/webextension-token-signing

-- 
 Dr. Ludovic Rousseau


From germano.massullo at gmail.com  Thu Apr  5 03:38:56 2018
From: germano.massullo at gmail.com (Germano Massullo)
Date: Thu, 5 Apr 2018 12:38:56 +0200
Subject: [Pcsclite-muscle] Firefox does not trigger pcsc start
In-Reply-To: <CAGstE8AF4pq3_dwefu+i7Ay8bG9HWeOZPXzgVvRxMKJBrs2o3g@mail.gmail.com>
References: <29928f39-931c-c529-f7f0-a5fdfc60b53e@gmail.com>
 <CAGstE8AF4pq3_dwefu+i7Ay8bG9HWeOZPXzgVvRxMKJBrs2o3g@mail.gmail.com>
Message-ID: <6e2e79c8-1d08-95a4-f4c7-19f9778b2cc7@gmail.com>

Il 05/04/2018 12:03, Ludovic Rousseau ha scritto:
> From your RedHat bug report
> https://bugzilla.redhat.com/show_bug.cgi?id=1545027 it looks like an
> issue with systemd activation.

In that bugreport some users mixed Fedora and RHEL/CentOS problems. The
difference is that on RHEL/CentOS you have to manually start pcscd
service while using all the previously mentioned packages. On Fedora
instead, the problem concerns only Firefox. I would start debugging
first Fedora problems, then RHEL/CentOS

> Please debug with a simple tool like pcsc_scan.
> Get it from http://ludovic.rousseau.free.fr/softwares/pcsc-tools/ or
> use the redhat package.
>
> Does pcsc_scan works in your configuration?

I plugged the USB reader with card inserted, then runned

$ pcsc_scan
PC/SC device scanner
V 1.4.25 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau at free.fr>
Compiled with PC/SC lite version: 1.8.22
SCardEstablishContext: Service not available.

# systemctl status pcscd
? pcscd.service - PC/SC Smart Card Daemon
?? Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect;
vendor preset: disabled)
?? Active: inactive (dead)

then after having runned

# systemctl start pcscd

I get

$ pcsc_scan
PC/SC device scanner
V 1.4.25 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau at free.fr>
Compiled with PC/SC lite version: 1.8.22
Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR 38U-CCID 00 00

Thu Apr? 5 12:32:33 2018
Reader 0: ACS ACR 38U-CCID 00 00
? Card state: Card inserted,
? ATR: ** removed by me **

ATR: ** removed by me **
+ TS = 3B --> Direct Convention
+ T0 = FA, Y(1): 1111, K: 10 (historical bytes)
? TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
??? 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
? TB(1) = 00 --> VPP is not electrically connected
? TC(1) = 00 --> Extra guard time: 0
? TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0
-----
? TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
-----
? TA(3) = FE --> IFSC: 254
? TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
+ Historical bytes: FE 65 49 44 20 2F 20 50 4B 49
? Category indicator byte: FE (proprietary format)
+ TCK = 03 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
** removed by me **
??????? Estonian Identity Card (EstEID v3.5 (10.2014) cold) (eID)
??????? http://id.ee/


Thank you



From ludovic.rousseau at gmail.com  Thu Apr  5 04:48:55 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Thu, 5 Apr 2018 13:48:55 +0200
Subject: [Pcsclite-muscle] Firefox does not trigger pcsc start
In-Reply-To: <6e2e79c8-1d08-95a4-f4c7-19f9778b2cc7@gmail.com>
References: <29928f39-931c-c529-f7f0-a5fdfc60b53e@gmail.com>
 <CAGstE8AF4pq3_dwefu+i7Ay8bG9HWeOZPXzgVvRxMKJBrs2o3g@mail.gmail.com>
 <6e2e79c8-1d08-95a4-f4c7-19f9778b2cc7@gmail.com>
Message-ID: <CAGstE8Bxqr3xvfZ+EyQKC6oBwx++QYNG80-w05p2jF4nDDcOrQ@mail.gmail.com>

2018-04-05 12:38 GMT+02:00 Germano Massullo <germano.massullo at gmail.com>:
> Il 05/04/2018 12:03, Ludovic Rousseau ha scritto:
>> From your RedHat bug report
>> https://bugzilla.redhat.com/show_bug.cgi?id=1545027 it looks like an
>> issue with systemd activation.
>
> In that bugreport some users mixed Fedora and RHEL/CentOS problems. The
> difference is that on RHEL/CentOS you have to manually start pcscd
> service while using all the previously mentioned packages. On Fedora
> instead, the problem concerns only Firefox. I would start debugging
> first Fedora problems, then RHEL/CentOS
>
>> Please debug with a simple tool like pcsc_scan.
>> Get it from http://ludovic.rousseau.free.fr/softwares/pcsc-tools/ or
>> use the redhat package.
>>
>> Does pcsc_scan works in your configuration?
>
> I plugged the USB reader with card inserted, then runned
>
> $ pcsc_scan
> PC/SC device scanner
> V 1.4.25 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau at free.fr>
> Compiled with PC/SC lite version: 1.8.22
> SCardEstablishContext: Service not available.
>
> # systemctl status pcscd
> ? pcscd.service - PC/SC Smart Card Daemon
>    Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect;
> vendor preset: disabled)
>    Active: inactive (dead)

The problem is a bogus systemd configuration.
Maybe the rpm package does not correctly configure the pcscd service.

It is a Fedora issue.

Bye

-- 
 Dr. Ludovic Rousseau


From germano.massullo at gmail.com  Thu Apr  5 10:27:47 2018
From: germano.massullo at gmail.com (Germano Massullo)
Date: Thu, 5 Apr 2018 19:27:47 +0200
Subject: [Pcsclite-muscle] Firefox does not trigger pcsc start
In-Reply-To: <CAGstE8Bxqr3xvfZ+EyQKC6oBwx++QYNG80-w05p2jF4nDDcOrQ@mail.gmail.com>
References: <29928f39-931c-c529-f7f0-a5fdfc60b53e@gmail.com>
 <CAGstE8AF4pq3_dwefu+i7Ay8bG9HWeOZPXzgVvRxMKJBrs2o3g@mail.gmail.com>
 <6e2e79c8-1d08-95a4-f4c7-19f9778b2cc7@gmail.com>
 <CAGstE8Bxqr3xvfZ+EyQKC6oBwx++QYNG80-w05p2jF4nDDcOrQ@mail.gmail.com>
Message-ID: <6ed72672-096f-06ca-ac2f-d991947de25c@gmail.com>

Problem solved!
I carefully checked pcsc service and socket systemd unit files,
installed new Fedora and CentOS 7 virtual machines, then tried again.
I found out that once you install pcsc-lite, the command
# systemctl status pcscd.socket
will say that the socket is inactive.
Since on other VMs and machines I found out that the socket was active,
I felt that such incongruence was so strange, then I had a kind of
inspiration and I tought: "mmh perhaps if I reboot the system the socket
will be active?"
I tried, and yes, a simply reboot after pcsc installation, solved the
problem.

Probably running a reload of all systemd unit files will make not
necessary a complete system reboot :-)



From ludovic.rousseau at gmail.com  Sun Apr 15 08:38:55 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Sun, 15 Apr 2018 17:38:55 +0200
Subject: [Pcsclite-muscle] New version of pcsc-tools: 1.5.3
Message-ID: <CAGstE8BQ4pVwDjPhrxrZu+Qxt3YjpSgA4ACtx5h=uL_jtq8-iA@mail.gmail.com>

Hello,

I just released a new version of pcsc-tools, a suite of tools for PC/SC.

The main changes are for the pcsc_scan command.

Changes:
1.5.3 - 15 April 2018, Ludovic ROUSSEAU
    - 253 new ATRs
    - pcsc_scan (thanks to Pascal J. Bourguignon):
     . add -v argument (default) for verbose
     . add -q argument for quiet
     . add -r argument to display the reader list
     . allow to use Control-C to break execution

https://ludovicrousseau.blogspot.fr/2018/04/new-version-of-pcsc-tools-153.html
http://ludovic.rousseau.free.fr/softwares/pcsc-tools/

-- 
 Dr. Ludovic Rousseau


From maximilian.stein at secunet.com  Tue Apr 17 06:12:26 2018
From: maximilian.stein at secunet.com (Maximilian Stein)
Date: Tue, 17 Apr 2018 15:12:26 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
Message-ID: <66cc6ee4-8ebc-b2de-3808-1769657ea4bd@secunet.com>

Hello all,

recently we stumbled upon another (rare) race condition in the
SCardGetStatusChange() function. I especially ask Maksim Ivanov and
Florian Kaiser kindly to share their opinion about the problem and the
proposed fix, since they did a good job in improving
SCardGetStatusChange/SCardCancel in the recent past.


The problem:
The problem is basically the small gap between fetching the reader
states from pcscd [winscard_clnt.c:1741 and 2119] and registering for
event notifications [winscard_clnt.c:2070]. If a notification is sent in
this time period, SCardGetStatusChange() will sleep until another event
or the internal time-out is reached. Consider the following flow of
execution and events:

Precondition: [client] knows the current state of all readers from a
previous call to SCardGetStatusChange() and no changes happened since
then. Basically consider a thread that monitors the reader states which
calls SCardGetStatusChange() in a loop.
1. [client] calls SCardGetStatusChange() and fetches the reader states
from pcscd (line 1741). The fetched states are equal to the already
known states.
2. [pcscd] notices a change in any terminal state (smartcard movement or
number of connected clients to the smartcard changes) and sends a signal
to all *registered* clients via EHSignalEventToClients(). [client] is
not yet registered for event notifications, so EHSignalEventToClients()
won't send anything.
3. [client] continues execution and compares the given reader states to
the states fetched before [pcscd] noticed the change. The states are
equal so it registers for event notifications (line 2070). No
notification was sent, so [client] sleeps until the internal time-out
(60 seconds) is reached.
4. [client] reaches the internal time-out and fetches the current reader
states from [pcscd]. Now the states are different and
SCardGetStatusChange returns.

In the end the state change is noticed thanks to the internal polling
mechanism, but in automated environments, 60 seconds is a very long time
until a state change is detected. The error is most likely to occur if
multiple readers are used and state changes are frequent. Even more
likely it occurs if reader state polling is used by pcscd, i.e. when the
IFD handler does not support asynchronous card event notification (no
capability TAG_IFD_POLLING_THREAD_WITH_TIMEOUT). Then multiple readers
can accumulate their events to be processed in a very small time frame.


Suggestion for a fix:
The proposed fix makes fetching the reader states and registering for
event notifications an atomic action. The command
CMD_WAIT_READER_STATE_CHANGE expected no return value anyway, so I made
it return the reader states equal to CMD_GET_READERS_STATE. The action
is protected by the ClientsWaitingForEvent_lock in eventhandler.c, which
prevents parallel calls of MSGSignalClient() via
EHSignalEventToClients(). This is necessary to prevent a signal before
the reader states are sent, which would appear as garbage in the client
socket.

With the proposed fix, the client is registered for events after the
reader states were fetched. So if any difference is found in the local
and remote state (so that SCardGetStatusChange() returns) we have to
unregister from events. This was not necessary before, but works just
like unregistering after a timeout. This could be refined by checking
why the loop was exited and only unregister if necessary.

Unfortunately the proposed fix will slightly alter the internal protocol
between libpcsclite and pcscd, breaking statically linked client
applications with newer pcscd versions.


Further related thoughts:
I'm a bit uncertain if my proposed fix works nicely with SCardCancel(),
because I can think of one very rare situation when
SCardGetStatusChange() times out and unregisters from event
notifications, then gets cancelled but is not informed about that. Then
it re-registers for notifications, because no changes happened. Thus it
will not returned despite it was cancelled. But this should have been an
issue even before my fix.

I think the notification mechanism could be improved by using "response
headers" analogous to the server side, or just an additional field
"command" in the data structs. This way every message related to reader
state events could be identified by the client and handled respectively.
As I understand it, some of the past issues were because of signal,
cancel or stop-reader-state-change messages messing up the client socket
data. With a command field it can be decided what data the client
received, and what data is still expected to be received.


Best regards
Maximilian Stein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SCardGetStatusChange-Fix-rare-race-condition.patch
Type: text/x-patch
Size: 8253 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20180417/9dff30bc/attachment.bin>

From ludovic.rousseau at gmail.com  Tue Apr 17 07:42:07 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Tue, 17 Apr 2018 16:42:07 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
In-Reply-To: <66cc6ee4-8ebc-b2de-3808-1769657ea4bd@secunet.com>
References: <66cc6ee4-8ebc-b2de-3808-1769657ea4bd@secunet.com>
Message-ID: <CAGstE8D4UiYW_LzxERA25aTa_KZ89g-=x3dpCSSyr+Enj5NdWA@mail.gmail.com>

2018-04-17 15:12 GMT+02:00 Maximilian Stein <maximilian.stein at secunet.com>:
> Hello all,

Hello,

> recently we stumbled upon another (rare) race condition in the
> SCardGetStatusChange() function. I especially ask Maksim Ivanov and
> Florian Kaiser kindly to share their opinion about the problem and the
> proposed fix, since they did a good job in improving
> SCardGetStatusChange/SCardCancel in the recent past.

Nice explanation. Thanks.

> Suggestion for a fix:
> The proposed fix makes fetching the reader states and registering for
> event notifications an atomic action. The command
> CMD_WAIT_READER_STATE_CHANGE expected no return value anyway, so I made
> it return the reader states equal to CMD_GET_READERS_STATE. The action
> is protected by the ClientsWaitingForEvent_lock in eventhandler.c, which
> prevents parallel calls of MSGSignalClient() via
> EHSignalEventToClients(). This is necessary to prevent a signal before
> the reader states are sent, which would appear as garbage in the client
> socket.
>
> With the proposed fix, the client is registered for events after the
> reader states were fetched. So if any difference is found in the local
> and remote state (so that SCardGetStatusChange() returns) we have to
> unregister from events. This was not necessary before, but works just
> like unregistering after a timeout. This could be refined by checking
> why the loop was exited and only unregister if necessary.

In CMD_WAIT_READER_STATE_CHANGE case you add:
+#ifdef USE_USB
+                /* wait until all readers are ready */
+                RFWaitForReaderInit();
+#endif

Why?

Bye

-- 
 Dr. Ludovic Rousseau


From maximilian.stein at secunet.com  Tue Apr 17 08:37:23 2018
From: maximilian.stein at secunet.com (Maximilian Stein)
Date: Tue, 17 Apr 2018 17:37:23 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
In-Reply-To: <CAGstE8D4UiYW_LzxERA25aTa_KZ89g-=x3dpCSSyr+Enj5NdWA@mail.gmail.com>
References: <66cc6ee4-8ebc-b2de-3808-1769657ea4bd@secunet.com>
 <CAGstE8D4UiYW_LzxERA25aTa_KZ89g-=x3dpCSSyr+Enj5NdWA@mail.gmail.com>
Message-ID: <9416793c-79b2-e54c-d651-e2c942be6665@secunet.com>

On 17.04.2018 16:42, Ludovic Rousseau wrote:
> 
> In CMD_WAIT_READER_STATE_CHANGE case you add:
> +#ifdef USE_USB
> +                /* wait until all readers are ready */
> +                RFWaitForReaderInit();
> +#endif
> 
> Why?

Because I use CMD_WAIT_READER_STATE_CHANGE to dump the reader states to
the client (done inside EHRegisterClientForEvent()). So I mindlessly
copied this behaviour from CMD_GET_READERS_STATE, which was used
originally by SCardGetStatusChange().

But thinking about it, there is still a chance that a new reader is
discovered and not fully initialized exactly while dumping the reader
states. If this is not a problem, the call to RFWaitForReaderInit()
could be removed from both CMD_GET_READERS_STATE and
CMD_WAIT_READER_STATE_CHANGE. Otherwise updating and dumping the reader
states should maybe be synchronized by a mutex to avoid invalid state
information.

Regards,
Maximilian


From emaxx at google.com  Tue Apr 17 13:21:18 2018
From: emaxx at google.com (Maksim Ivanov)
Date: Tue, 17 Apr 2018 22:21:18 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
Message-ID: <CAH=wB8w3nSvGD16mMEobiYATNTU0Krie9gRW6J1JKrvnz0JJqQ@mail.gmail.com>

Hello,

Sorry, I haven't looked closely through the proposed patch, although
the bug explanation seems convincing.

My two cents: breaking the protocol's binary compatibility is an
unfortunate change to do. This will likely require issuing a new major
version of PCSC-Lite; and as switching of significant part of client
applications onto this new version will definitely take a while, this
may result in having to support two major versions in parallel for a
long time.
So I think it makes sense to investigate more whether some other
approaches are possible, which don't require backwards-incompatible
protocol changes.

For example, a simple workaround would be to make the polling interval
exponentially growing (starting, for instance, from 1 second, or even
from 0.1 second, and being capped at 60 sec), instead of being fixed
at 60 seconds.
This, obviously, won't be a real solution for the data race - the
worst-case scenario of 60 seconds of waiting would still be possible -
but should help in cases like the one described in the initial message
(IIUC).


Regards,
Maksim


From ludovic.rousseau at gmail.com  Wed Apr 18 11:58:45 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Wed, 18 Apr 2018 20:58:45 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
In-Reply-To: <9416793c-79b2-e54c-d651-e2c942be6665@secunet.com>
References: <66cc6ee4-8ebc-b2de-3808-1769657ea4bd@secunet.com>
 <CAGstE8D4UiYW_LzxERA25aTa_KZ89g-=x3dpCSSyr+Enj5NdWA@mail.gmail.com>
 <9416793c-79b2-e54c-d651-e2c942be6665@secunet.com>
Message-ID: <CAGstE8C_QnUMHonzLk5dZ7DJMh9PThqX3K80LWXhxtEESKxmQQ@mail.gmail.com>

2018-04-17 17:37 GMT+02:00 Maximilian Stein <maximilian.stein at secunet.com>:
> On 17.04.2018 16:42, Ludovic Rousseau wrote:
>>
>> In CMD_WAIT_READER_STATE_CHANGE case you add:
>> +#ifdef USE_USB
>> +                /* wait until all readers are ready */
>> +                RFWaitForReaderInit();
>> +#endif
>>
>> Why?
>
> Because I use CMD_WAIT_READER_STATE_CHANGE to dump the reader states to
> the client (done inside EHRegisterClientForEvent()). So I mindlessly
> copied this behaviour from CMD_GET_READERS_STATE, which was used
> originally by SCardGetStatusChange().

Exact.
I added the call to RFWaitForReaderInit() in
https://salsa.debian.org/rousseau/PCSC/commit/3cf4188c3eee4d7fafaa361adfda0075cdb7a997

The same should be used for CMD_WAIT_READER_STATE_CHANGE for the same reason.

> But thinking about it, there is still a chance that a new reader is
> discovered and not fully initialized exactly while dumping the reader
> states. If this is not a problem, the call to RFWaitForReaderInit()
> could be removed from both CMD_GET_READERS_STATE and
> CMD_WAIT_READER_STATE_CHANGE. Otherwise updating and dumping the reader
> states should maybe be synchronized by a mutex to avoid invalid state
> information.

I described the problem solved by RFWaitForReaderInit() in the patch
commit message.
I am happy to describe the problem a patch is supposed to fix. 7 years
later I am not able to remind why I did what I did.

Your patch looks good.
Thanks

-- 
 Dr. Ludovic Rousseau


From ludovic.rousseau at gmail.com  Wed Apr 18 12:04:33 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Wed, 18 Apr 2018 21:04:33 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
In-Reply-To: <CAH=wB8w3nSvGD16mMEobiYATNTU0Krie9gRW6J1JKrvnz0JJqQ@mail.gmail.com>
References: <CAH=wB8w3nSvGD16mMEobiYATNTU0Krie9gRW6J1JKrvnz0JJqQ@mail.gmail.com>
Message-ID: <CAGstE8BB6fGT+UP1taNKNFK1si_JOPU544hMHXhdpK66gWa8_g@mail.gmail.com>

2018-04-17 22:21 GMT+02:00 Maksim Ivanov <emaxx at google.com>:
> Hello,

Hello,

> Sorry, I haven't looked closely through the proposed patch, although
> the bug explanation seems convincing.
>
> My two cents: breaking the protocol's binary compatibility is an
> unfortunate change to do. This will likely require issuing a new major
> version of PCSC-Lite; and as switching of significant part of client
> applications onto this new version will definitely take a while, this
> may result in having to support two major versions in parallel for a
> long time.
> So I think it makes sense to investigate more whether some other
> approaches are possible, which don't require backwards-incompatible
> protocol changes.

I would release a new major version of pcsc-lite if I break the API or ABI.
Here the change in internal and will not break anything if you update
pcscd and libpcsclite at the same time (as you should always do).

Changing the client-daemon protocol is not a problem for me.

If you are linking statically with libpcsclite you would get an error
on the first PC/SC call because the protocol will not match.
I guess that people using static linking do this for a valid reason
and they know the effects.

Or maybe you have convincing arguments?

Bye

-- 
 Dr. Ludovic Rousseau


From nkak at kth.se  Thu Apr 19 04:35:53 2018
From: nkak at kth.se (Nikolaos Kakouros)
Date: Thu, 19 Apr 2018 11:35:53 +0000
Subject: [Pcsclite-muscle] IDBridge K3000 is not found by pcsc_scan
Message-ID: <1524137752982.38376@kth.se>

Hello,

I have a IDBridge K3000 device. I am trying to use it on either Arch Linux (fully updated) or Ubuntu 16.04.2 installed on a Dell laptop with an Intel i5 processor. I have tried with different USB ports. In both cases, I fail.

On Arch Linux, I compiled the USB CCID driver from a fresh git checkout. The version of pcsc-lite is 1.8.23 and the version of pcsc-tools is 1.5.2.

On Ubuntu 16.04, I used apt to install whatever is in the repos. So, pcsc-tools is 1.4.25, libccid is 1.4.22 and pcscd is 1.8.14. The output of pcscd --version is:

pcsc-lite version 1.8.14.
Copyright (C) 1999-2002 by David Corcoran <corcoran at musclecard.com>.
Copyright (C) 2001-2011 by Ludovic Rousseau <ludovic.rousseau at free.fr>.
Copyright (C) 2003-2004 by Damien Sauveron <sauveron at labri.fr>.
Report bugs to <muscle at lists.musclecard.com>.
Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/etc/reader.conf.d

Sorry for the sans serif font but if I include formatting the email bounces back.

The device is recognized by the Linux kernel. The output of dmesg is:

[ 4904.459100] usb 1-3: new high-speed USB device number 33 using xhci_hcd
[ 4904.600782] usb 1-3: New USB device found, idVendor=08e6, idProduct=8140
[ 4904.600784] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4904.600786] usb 1-3: Product: IDBridge K3000
[ 4904.600787] usb 1-3: Manufacturer: GEMALTO
[ 4904.600788] usb 1-3: SerialNumber: C840357100001E52

I run pcscd in debug mode (sudo LIBCCID_ifdLogLevel=0x000F pcscd --foreground --debug --apdu --color | tee log.txt). When the usb device is plugged in, it reacts and I see:

10516944 hotplug_libudev.c:651:HPEstablishUSBNotifications() USB Device add
00000176 hotplug_libudev.c:297:get_driver() Looking for a driver for VID: 0x08E6, PID: 0x8140, path: /dev/bus/usb/001/035
00000207 hotplug_libudev.c:651:HPEstablishUSBNotifications() USB Device add
00000137 hotplug_libudev.c:297:get_driver() Looking for a driver for VID: 0x08E6, PID: 0x8140, path: /dev/bus/usb/001/035

The sudo ./src/parse utility shows:

Parsing USB bus/device: 08E6:8140 (bus 1, device 35)
 idVendor:  0x08E6  iManufacturer: GEMALTO
 idProduct: 0x8140  iProduct: IDBridge K3000
  NOT a CCID/ICCD device

The details of the usb drive as detected by sudo lsusb -v are:

Bus 001 Device 035: ID 08e6:8140 Gemalto (was Gemplus)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x08e6 Gemalto (was Gemplus)
  idProduct          0x8140
  bcdDevice            2.10
  iManufacturer           1 GEMALTO
  iProduct                2 IDBridge K3000
  iSerial                 3 C840357100001E52
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           57
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.02
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     110
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

I searched the mailing list and the only relevant thread I found was http://lists.infradead.org/pipermail/pcsclite-muscle/2017-May/000885.html . If I understood correctly there, some fixes are already in the latest version.

Am I doing sth wrong? Could there be sth wrong with the specific USB device I have? Can I somehow overcome this issue?

Thank you for your time.
Nikolaos


From ludovic.rousseau at gmail.com  Thu Apr 19 05:31:37 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Thu, 19 Apr 2018 14:31:37 +0200
Subject: [Pcsclite-muscle] IDBridge K3000 is not found by pcsc_scan
In-Reply-To: <1524137752982.38376@kth.se>
References: <1524137752982.38376@kth.se>
Message-ID: <CAGstE8AAjnBE8gQe-tSvrbNeS8bvV2RzhxvV8rfjx-MA8DwvPg@mail.gmail.com>

2018-04-19 13:35 GMT+02:00 Nikolaos Kakouros <nkak at kth.se>:
> Hello,

Hello,

> I have a IDBridge K3000 device. I am trying to use it on either Arch Linux (fully updated) or Ubuntu 16.04.2 installed on a Dell laptop with an Intel i5 processor. I have tried with different USB ports. In both cases, I fail.
>
> On Arch Linux, I compiled the USB CCID driver from a fresh git checkout. The version of pcsc-lite is 1.8.23 and the version of pcsc-tools is 1.5.2.
>
> On Ubuntu 16.04, I used apt to install whatever is in the repos. So, pcsc-tools is 1.4.25, libccid is 1.4.22 and pcscd is 1.8.14. The output of pcscd --version is:
>
> pcsc-lite version 1.8.14.
> Copyright (C) 1999-2002 by David Corcoran <corcoran at musclecard.com>.
> Copyright (C) 2001-2011 by Ludovic Rousseau <ludovic.rousseau at free.fr>.
> Copyright (C) 2003-2004 by Damien Sauveron <sauveron at labri.fr>.
> Report bugs to <muscle at lists.musclecard.com>.
> Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/etc/reader.conf.d
>
> Sorry for the sans serif font but if I include formatting the email bounces back.
>
> The device is recognized by the Linux kernel. The output of dmesg is:
>
> [ 4904.459100] usb 1-3: new high-speed USB device number 33 using xhci_hcd
> [ 4904.600782] usb 1-3: New USB device found, idVendor=08e6, idProduct=8140
> [ 4904.600784] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 4904.600786] usb 1-3: Product: IDBridge K3000
> [ 4904.600787] usb 1-3: Manufacturer: GEMALTO
> [ 4904.600788] usb 1-3: SerialNumber: C840357100001E52
>
> I run pcscd in debug mode (sudo LIBCCID_ifdLogLevel=0x000F pcscd --foreground --debug --apdu --color | tee log.txt). When the usb device is plugged in, it reacts and I see:
>
> 10516944 hotplug_libudev.c:651:HPEstablishUSBNotifications() USB Device add
> 00000176 hotplug_libudev.c:297:get_driver() Looking for a driver for VID: 0x08E6, PID: 0x8140, path: /dev/bus/usb/001/035
> 00000207 hotplug_libudev.c:651:HPEstablishUSBNotifications() USB Device add
> 00000137 hotplug_libudev.c:297:get_driver() Looking for a driver for VID: 0x08E6, PID: 0x8140, path: /dev/bus/usb/001/035
>
> The sudo ./src/parse utility shows:
>
> Parsing USB bus/device: 08E6:8140 (bus 1, device 35)
>  idVendor:  0x08E6  iManufacturer: GEMALTO
>  idProduct: 0x8140  iProduct: IDBridge K3000
>   NOT a CCID/ICCD device

The Gemalto IDBridge K3000 supported by the CCID driver has idProduct
0x8141 not 0x8140
https://ccid.apdu.fr/ccid/supported.html#0x08E60x8141
https://ccid.apdu.fr/ccid/readers/Gemalto_IDBridge_K3000.txt

> Am I doing sth wrong? Could there be sth wrong with the specific USB device I have? Can I somehow overcome this issue?

You have to enable the CCID mode on the K3000.
There should be a Windows tool to do that but I do not have it.

Bye

-- 
 Dr. Ludovic Rousseau


From ludovic.rousseau at gmail.com  Mon Apr 23 08:18:59 2018
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Mon, 23 Apr 2018 17:18:59 +0200
Subject: [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
In-Reply-To: <CAGstE8C_QnUMHonzLk5dZ7DJMh9PThqX3K80LWXhxtEESKxmQQ@mail.gmail.com>
References: <66cc6ee4-8ebc-b2de-3808-1769657ea4bd@secunet.com>
 <CAGstE8D4UiYW_LzxERA25aTa_KZ89g-=x3dpCSSyr+Enj5NdWA@mail.gmail.com>
 <9416793c-79b2-e54c-d651-e2c942be6665@secunet.com>
 <CAGstE8C_QnUMHonzLk5dZ7DJMh9PThqX3K80LWXhxtEESKxmQQ@mail.gmail.com>
Message-ID: <CAGstE8BryaGVXaXpY-oWMdLUiC0zCSQFiRsArp8_dLVW+jU9hg@mail.gmail.com>

2018-04-18 20:58 GMT+02:00 Ludovic Rousseau <ludovic.rousseau at gmail.com>:
> 2018-04-17 17:37 GMT+02:00 Maximilian Stein <maximilian.stein at secunet.com>:
>
> Your patch looks good.

Pushed in https://salsa.debian.org/rousseau/PCSC/commit/984f84df10e2d0f432039e3b31f94c74e95092eb

Thanks again Maximilien.

-- 
 Dr. Ludovic Rousseau


