1. 16 Jan, 2019 1 commit
    • Ludovic Rousseau's avatar
      Doc: more explicit documentation for −−auto−exit · e641eaa7
      Ludovic Rousseau authored
      pcscd does not exit after 60 seconds but after 60 seconds of inactivity
      after the release of the last PC/SC context.
      If you start pcscd with −−auto−exit but do run any PC/SC application
      then pcscd will NOT exit after 60 seconds.
      Thanks to Matthias Apitz for the bug report.
  2. 14 Jan, 2019 2 commits
    • vegaMato's avatar
      Remove usage of function chmod(2) to use fchmod(2) · 36c8eae8
      vegaMato authored
      Race condition possibility; CWE-362: Concurrent Execution using Shared
      Resource with Improper Synchronization ('Race Condition')
      Thanks to PA193 project
    • St4lkerino's avatar
      Fix realloc(3) error handling · 43004384
      St4lkerino authored
      From realloc(3) manpage:
             The realloc() function returns a pointer to the newly allocated memory,
             which  is  suitably  aligned for any built-in type and may be different
             from ptr, or NULL if the request fails.  If size was equal to 0, either
             NULL  or  a  pointer  suitable  to be passed to free() is returned.  If
             realloc() fails, the original block is left untouched; it is not  freed
             or moved.
      If realloc() fails then the memory that was previously allocated needs
      to be freed, or it will create a memory leak.
      It was not a real problem because if realloc(3) failed then pcscd would
      exit immediatly and the memory would not leak for a long time.
      Thanks to PA193 project
  3. 03 Jan, 2019 1 commit
  4. 15 Dec, 2018 1 commit
  5. 12 Dec, 2018 1 commit
  6. 07 Dec, 2018 1 commit
  7. 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.
  8. 15 Nov, 2018 1 commit
  9. 12 Oct, 2018 5 commits
    • Ludovic Rousseau's avatar
      Release 1.8.23 · 73d95ada
      Ludovic Rousseau authored
    • 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
    • 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))
    • 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);
    • 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);
  10. 09 Oct, 2018 1 commit
  11. 08 Oct, 2018 3 commits
  12. 04 Oct, 2018 3 commits
  13. 02 Oct, 2018 2 commits
  14. 15 Sep, 2018 1 commit
  15. 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
              struct wait_reader_state_change waStr = {0};
    • 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
                                      struct wait_reader_state_change waStr = {0};
    • 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
      Thanks to Sam Van Den Berge for the bug report
      "[Pcsclite-muscle] SCardCancel broken"
      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
      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!
  16. 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.
    • 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:
      Thanks to Alan Kozlay for the bug report and patch.
    • Ludovic Rousseau's avatar
      Doxygen: fix warning · 08664ae6
      Ludovic Rousseau authored
      PCSC/src/PCSC/ifdhandler.h:84: warning: Unsupported xml/html tag
      <string> found
    • 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
      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)
    • 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.
  17. 28 May, 2018 1 commit
  18. 21 May, 2018 3 commits
  19. 18 May, 2018 2 commits
  20. 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()
      " 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
      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 "
  21. 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.