1. 15 Dec, 2018 1 commit
  2. 12 Dec, 2018 1 commit
  3. 07 Dec, 2018 1 commit
  4. 26 Nov, 2018 1 commit
    • Ludovic Rousseau's avatar
      MSGRemoveContext: remove dead code · 53ab2bc8
      Ludovic Rousseau authored
      Issue found by Coverity:
      >>>     CID 1441490:  Code maintainability issues  (UNUSED_VALUE)
      >>>     Assigning value "2148532329L" to "rv" here, but that stored value is overwritten before it can be used.
      53ab2bc8
  5. 15 Nov, 2018 1 commit
  6. 12 Oct, 2018 5 commits
    • Ludovic Rousseau's avatar
      Release 1.8.23 · 73d95ada
      Ludovic Rousseau authored
      73d95ada
    • Ludovic Rousseau's avatar
      Fix compiler warning: output may be truncated · eaaf8eda
      Ludovic Rousseau authored
      winscard_msg.c: In function ‘ClientSetupSession’:
      winscard_msg.c:134:2: warning: ‘strncpy’ output may be truncated copying 108 bytes from a string of length 109 [-Wstringop-truncation]
        strncpy(svc_addr.sun_path, socketName, sizeof(svc_addr.sun_path));
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      The source was sizeof(struct sockaddr_un) bytes long.
      But the destination was sizeof(svc_addr.sun_path) bytes long only.
      
      svc_addr is a struct sockaddr_un but the sun_path field is shorter (1
      byte shorter according to the compiler) than the complete struct
      sockaddr_un.
      eaaf8eda
    • Ludovic Rousseau's avatar
      Fix compiler warning: cast between incompatible function · 2bef0948
      Ludovic Rousseau authored
      hotplug_libudev.c: In function ‘HPRegisterForHotplugEvents’:
      hotplug_libudev.c:769:3: warning: cast between incompatible function types from ‘void (*)(void *)’ to ‘void * (*)(void *)’ [-Wcast-function-type]
         (PCSCLITE_THREAD_FUNCTION( )) HPEstablishUSBNotifications, udev_monitor))
         ^
      2bef0948
    • Ludovic Rousseau's avatar
      Fix compiler warning: cast between incompatible function · 3c80087b
      Ludovic Rousseau authored
      eventhandler.c: In function ‘EHSpawnEventHandler’:
      eventhandler.c:234:3: warning: cast between incompatible function types from ‘void (*)(READER_CONTEXT *)’ {aka ‘void (*)(struct ReaderContext *)’} to ‘void * (*)(void *)’ [-Wcast-function-type]
         (PCSCLITE_THREAD_FUNCTION( ))EHStatusHandlerThread, (LPVOID) rContext);
         ^
      3c80087b
    • Ludovic Rousseau's avatar
      Fix compiler warning: cast between incompatible function · d6ba979b
      Ludovic Rousseau authored
      winscard_svc.c: In function ‘CreateContextThread’:
      winscard_svc.c:237:3: warning: cast between incompatible function types from ‘void (*)(void *)’ to ‘void * (*)(void *)’ [-Wcast-function-type]
         (PCSCLITE_THREAD_FUNCTION( )) ContextThread, (LPVOID) newContext);
         ^
      d6ba979b
  7. 09 Oct, 2018 1 commit
  8. 08 Oct, 2018 3 commits
  9. 04 Oct, 2018 3 commits
  10. 02 Oct, 2018 2 commits
  11. 15 Sep, 2018 1 commit
  12. 27 Jul, 2018 3 commits
    • Ludovic Rousseau's avatar
      Fix compiler warning: missing field 'rv' initializer · ded26af3
      Ludovic Rousseau authored
      winscard_svc.c:814:44: warning: missing field 'rv' initializer
            [-Wmissing-field-initializers]
              struct wait_reader_state_change waStr = {0};
                                                        ^
      ded26af3
    • Ludovic Rousseau's avatar
      Fix compiler warning missing field 'rv' initializer · e632d595
      Ludovic Rousseau authored
      winscard_svc.c:428:47: warning: missing field 'rv' initializer
            [-Wmissing-field-initializers]
                                      struct wait_reader_state_change waStr = {0};
      e632d595
    • Ludovic Rousseau's avatar
      Fix SCardGetStatusChange() broken in a previous patch 984f84df · 54224a4c
      Ludovic Rousseau authored
      The patch in 984f84df broke the
      execution of SCardGetStatusChange() when SCardCancel() is used.
      
      The client was waiting for a message that was never sent by the server.
      
      Fortunately the broken code was never released in a stable version of
      pcsc-lite.
      
      Thanks to Sam Van Den Berge for the bug report
      "[Pcsclite-muscle] SCardCancel broken"
      http://lists.infradead.org/pipermail/pcsclite-muscle/2018-July/001096.html
      
      Hello,
      
      It seems like SCardGetStatusChange is currently broken.
      This can be tested with UnitaryTests/SCardCancel.
      
      Before commit 984f84df:
      
      $ LD_LIBRARY_PATH=../src/.libs/ ./SCardCancel
      SCardEstablishContext:[0x00000000] Command successful.
      Press Enter to cancel within 3 seconds
      Entering blocking call
      
      Calling SCardCancel...
      SCardGetStatusChange:[0x80100002] Command cancelled.
      Blocking call canceled
      Good
      SCardCancel:[0x00000000] Command successful.
      SCardReleaseContext:[0x00000000] Command successful.
      Waiting thread...
      
      After commit 984f84df:
      
      $ LD_LIBRARY_PATH=../src/.libs/ ./SCardCancel
      SCardEstablishContext:[0x00000000] Command successful.
      Press Enter to cancel within 3 seconds
      Entering blocking call
      
      Calling SCardCancel...
      SCardCancel:[0x00000000] Command successful.
      
      <<<<<<<<< SCardGetStatusChange hangs here >>>>>>>>>
      
      I don't have a fix but I just wanted to report this. Besides this big
      thank you for all your great work!
      
      Kr,
      Sam.
      54224a4c
  13. 29 Jun, 2018 5 commits
    • Ludovic Rousseau's avatar
      Doxygen: documentation moved to pcsclite.apdu.fr · ddf72587
      Ludovic Rousseau authored
      Update the update.sh script to update the Doxygen documentation pages.
      ddf72587
    • Ludovic Rousseau's avatar
      Allow "=" in serial driver filenames · 01677078
      Ludovic Rousseau authored
      For example the configuration:
      LIBPATH       /tmp/lib/pcsc/drivers/lib=ccid.dylib
      failed with:
      00000057 configfile.l:165:evaluatetoken() Error with library /tmp/lib/pcsc/drivers/lib: No such file or directory
      
      The problem was detected on Android 8.0 with file names such as:
      /data/app/com.baimobile.android.enterprise.credential.service-4wM9GBtoaS74ZiA0Y25YuQ==/lib/arm64/lib_some_reader_driver.so
      
      Thanks to Alan Kozlay for the bug report and patch.
      01677078
    • Ludovic Rousseau's avatar
      Doxygen: fix warning · 08664ae6
      Ludovic Rousseau authored
      PCSC/src/PCSC/ifdhandler.h:84: warning: Unsupported xml/html tag
      <string> found
      08664ae6
    • Ludovic Rousseau's avatar
      Doxygen: do not document disabled functions · d412c4bb
      Ludovic Rousseau authored
      If USE_LIBSYSTEMD is not defined then ListenExistingSocket() is not
      implemented and the associated Doxygen documentation should not be
      present.
      
      Fix Doxygen warning:
      PCSC/src/winscard_msg_srv.c:193: warning: argument 'fd' of command @param is not found in the argument list of ProcessEventsServer(uint32_t *pdwClientID)
      d412c4bb
    • Ludovic Rousseau's avatar
      Doxygen: Use " " for FRIENDLYNAME · e4f50dc1
      Ludovic Rousseau authored
      The FRIENDLYNAME declaration for reader.conf files must use " " if space
      characters are present in the name.
      e4f50dc1
  14. 28 May, 2018 1 commit
  15. 21 May, 2018 3 commits
  16. 18 May, 2018 2 commits
  17. 23 Apr, 2018 1 commit
    • Ludovic Rousseau's avatar
      Fix a rare race condition in SCardGetStatusChange() · 984f84df
      Ludovic Rousseau authored
      Thanks to Maximilian Stein for the patch
      
      [Pcsclite-muscle] Rare race condition in SCardGetStatusChange()
      http://lists.infradead.org/pipermail/pcsclite-muscle/2018-April/001068.html
      
      " 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 "
      984f84df
  18. 22 Mar, 2018 1 commit
    • Nicolas Dusart's avatar
      Simclist: avoid to divide by zero in list_findpos() · 0127d3c7
      Nicolas Dusart authored
      A division by zero with float is undefined in C.
      For example gcc 6.3.0 reports (when detected):
      dividebyzero.c:5:20: warning: division by zero [-Wdiv-by-zero]
        float a = (float)1/0;
      
      But the code does NOT crash. The value of a is just infinity.
      
      The problem is when Free Pascal runtime is used. In this case the code crashed.
      0127d3c7
  19. 02 Feb, 2018 1 commit
    • Ludovic Rousseau's avatar
      pcsc-spy: correctly handle incomplete log file · 2f99e761
      Ludovic Rousseau authored
      If the application is interrupted in the middle of a PC/SC call then we
      do not get the returned values of the PC/SC call.
      The total execution time is then not known and -1 seconds is displayed
      instead.
      2f99e761
  20. 19 Dec, 2017 1 commit
  21. 18 Dec, 2017 1 commit
  22. 14 Nov, 2017 1 commit
    • Ludovic Rousseau's avatar
      spy: add support SCardStatus() with NULL pcbAtrLen · 1dde8427
      Ludovic Rousseau authored
      If an application calls SCardStatus() with pcbAtrLen = NULL then the trace
      interpretation was wrong.
      
      The problematic trace was:
      7F9414EF6700@>|1510667088|620972|SCardStatus
      7F9414EF6700@0x7B0DDEA3
      7F9414EF6700@NULL
      7F9414EF6700@NULL
      7F9414EF6700@NULL
      7F9414EF6700@""
      7F9414EF6700@NULL
      7F9414EF6700@NULL
      7F9414EF6700@NULL
      7F9414EF6700@<|1510667088|621107|SCardStatus|Command successful.|0x00000000
      
      SCardStatus
       i hCard: 0x7B0DDEA3
       i pcchReaderLen NULL
       i pcbAtrLen NULL
       o cchReaderLen NULL
       o mszReaderName ""
       o dwState NULL
       o dwProtocol NULL
       o bAtrLen NULL
       o bAtr
       => Command successful. (SCARD_S_SUCCESS [0x00000000])  [0.000135]
      
      In the trace above the value bAtr is not known (bAtrLen has no value) so
      nothing is displayed.
      
      A more classic trace is:
      7FF91179D700@>|1510668989|105007|SCardStatus
      7FF91179D700@0x2E753ED9
      7FF91179D700@0x00000000
      7FF91179D700@0x00000000
      7FF91179D700@0x0000001D
      7FF91179D700@NULL
      7FF91179D700@0x00050034
      7FF91179D700@0x00000001
      7FF91179D700@0x00000014
      7FF91179D700@NULL
      7FF91179D700@<|1510668989|105301|SCardStatus|Command successful.|0x00000000
      7FF91179D700@>|1510668989|105306|SCardStatus
      7FF91179D700@0x2E753ED9
      7FF91179D700@0x0000001D
      7FF91179D700@0x00000021
      7FF91179D700@0x0000001D
      7FF91179D700@Gemalto PC Twin Reader 00 00
      7FF91179D700@0x00050034
      7FF91179D700@0x00000001
      7FF91179D700@0x00000014
      7FF91179D700@3B 7F 96 00 00 80 31 80 65 B0 85 03 00 EF 12 0F FE 82 90 00
      7FF91179D700@<|1510668989|105365|SCardStatus|Command successful.|0x00000000
      
      giving:
      SCardStatus
       i hCard: 0x2E753ED9
       i pcchReaderLen 0x00000000 (0)
       i pcbAtrLen 0x00000000 (0)
       o cchReaderLen 0x0000001D (29)
       o mszReaderName NULL
       o dwState 0x00050034 (327732)
       o dwProtocol 0x00000001 (1)
       o bAtrLen 0x00000014 (20)
       o bAtr NULL
       => Command successful. (SCARD_S_SUCCESS [0x00000000])  [0.000294]
      SCardStatus
       i hCard: 0x2E753ED9
       i pcchReaderLen 0x0000001D (29)
       i pcbAtrLen 0x00000021 (33)
       o cchReaderLen 0x0000001D (29)
       o mszReaderName Gemalto PC Twin Reader 00 00
       o dwState 0x00050034 (327732)
       o dwProtocol 0x00000001 (1)
       o bAtrLen 0x00000014 (20)
       o bAtr 3B 7F 96 00 00 80 31 80 65 B0 85 03 00 EF 12 0F FE 82 90 00
       => Command successful. (SCARD_S_SUCCESS [0x00000000])  [0.000059]
      1dde8427