!20 update to 1.9.4

From: @markeryang
Reviewed-by: @liuzhiqiang26
Signed-off-by: @liuzhiqiang26

0000-pcsc-lite-change-to-use-python3-for-pcsc-spy.patch

@@ -1,26 +0,0 @@
-From 5a0c5fcd6371f1e1b5b18b2888d9e3304e402177 Mon Sep 17 00:00:00 2001
-From: Shijie Luo <luoshijie1@huawei.com>
-Date: Tue, 18 Feb 2020 09:43:11 +0800
-Subject: [PATCH] pcsc-lite:change to use python3 for pcsc-spy
-
-pcsc-spy is needed when we compile pcsc-lite, change to
-use python3 instead of python2.
-
-Signed-off-by: Shijie Luo <luoshijie1@huawei.com>
----
- src/spy/pcsc-spy | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/spy/pcsc-spy b/src/spy/pcsc-spy
-index bf49482..7b9c5f3 100755
---- a/src/spy/pcsc-spy
-+++ b/src/spy/pcsc-spy
-@@ -1,4 +1,4 @@
--#! /usr/bin/python
-+#! /usr/bin/python3
- 
- """
- #    Display PC/SC functions arguments
--- 
-1.8.3.1
-

0001-Do-not-possibly-lock-a-reader-if-allocating-hCard-fa.patch

@@ -1,78 +0,0 @@
-From 36bc9446b40fa3c6ac12312b934f4d7131659087 Mon Sep 17 00:00:00 2001
-From: Ludovic Rousseau <ludovic.rousseau@free.fr>
-Date: Wed, 5 Aug 2020 17:59:41 +0200
-Subject: [PATCH 01/13] Do not (possibly) lock a reader if allocating hCard
- fails
-
-In case of SCardConnect() the reader may be locked in
-SCARD_SHARE_EXCLUSIVE mode if internal SCardConnect() works but
-MSGAddHandle() fails because the list of handle is full.
-
-You need to start pcscd with "--max-card-handle-per-reader n" with
-n > 200 or the 200 limit (default value) will be hit in internal
-SCardConnect() and MSGAddHandle() would not be called.
-
-Thanks to Maksim Ivanov for the bug report
-"[Pcsclite-muscle] SCardConnect behavior with invalid contexts"
-http://lists.infradead.org/pipermail/pcsclite-muscle/2020-July/001095.html
-
-" Hello,
-
-I believe that there's a potential problem with the SCardConnect
-implementation that it doesn't check the received SCARDCONTEXT
-*before* executing the command. This might result in an unexpected
-state, where the SCardConnect() caller receives an error code
-meanwhile the connection to the card is actually established (which,
-for example, might be an exclusive connection that prevents anyone
-else from connecting to the card).
-
-In detail, the ContextThread() function in winscard_svc.c, when
-receiving the SCARD_CONNECT command, calls first SCardConnect() from
-winscard.c, and then MSGAddHandle(). The former ignores SCARDCONTEXT
-and, if possible, establishes a connection to the card. The latter
-does check the SCARDCONTEXT value, but this happens after the
-connection is already established, and its error is just returned to
-the caller (without closing the just-opened connection).
-
-Would it make sense to add a check of SCARDCONTEXT before calling
-SCardConnect(), and/or to call SCardDisconnect() if MSGAddHandle()
-fails?
-
-Regards,
-Maksim "
----
- src/winscard_svc.c | 8 +++++++-
- 1 file changed, 7 insertions(+), 1 deletion(-)
-
-diff --git a/src/winscard_svc.c b/src/winscard_svc.c
-index cdeac33..c0df008 100644
---- a/src/winscard_svc.c
-+++ b/src/winscard_svc.c
-@@ -507,9 +507,15 @@ static void * ContextThread(LPVOID newContext)
- 				coStr.dwActiveProtocol = dwActiveProtocol;
- 
- 				if (coStr.rv == SCARD_S_SUCCESS)
-+				{
- 					coStr.rv = MSGAddHandle(coStr.hContext, coStr.hCard,
- 						threadContext);
- 
-+					/* if storing the hCard fails we disconnect */
-+					if (coStr.rv != SCARD_S_SUCCESS)
-+						SCardDisconnect(coStr.hCard, SCARD_LEAVE_CARD);
-+				}
-+
- 				WRITE_BODY(coStr);
- 			}
- 			break;
-@@ -963,7 +969,7 @@ static LONG MSGAddHandle(SCARDCONTEXT hContext, SCARDHANDLE hCard,
- 		if (listLength >= contextMaxCardHandles)
- 		{
- 			Log4(PCSC_LOG_DEBUG,
--				"Too many card handles for thread context @%p: %d (max is %d)"
-+				"Too many card handles for thread context @%p: %d (max is %d). "
- 				"Restart pcscd with --max-card-handle-per-thread value",
- 				threadContext, listLength, contextMaxCardHandles);
- 			retval = SCARD_E_NO_MEMORY;
--- 
-1.8.3.1
-

0002-Fix-a-hang-in-SCardTransmit.patch

@@ -1,56 +0,0 @@
-From 38dfe5c1f474db519e1f7e31cf714ba5d4c6cfa4 Mon Sep 17 00:00:00 2001
-From: Ludovic Rousseau <ludovic.rousseau@free.fr>
-Date: Wed, 5 Aug 2020 18:57:30 +0200
-Subject: [PATCH 02/13] Fix a hang in SCardTransmit()
-
-In some special conditions it is possible to make SCardTransmit() to
-hang forever in pcscd and generates a denial of service.
-
-I was able to reproduce the problem using a sample C code.
-
-Thanks to Maksim Ivanov for the bug report
-"[Pcsclite-muscle] Potential hang in SCardTransmit"
-http://lists.infradead.org/pipermail/pcsclite-muscle/2020-July/001096.html
-
-" Hello,
-
-It seems that there's (at least half-hypothetical) scenario when
-SCardTransmit may hang.
-
-The combination is:
-the service's |readerState| is (SCARD_PRESENT | SCARD_POWERED |
-SCARD_NEGOTIABLE);
-the service's |cardProtocol| is SCARD_PROTOCOL_UNDEFINED (right after
-power-up);
-the caller's |pioSendPci->dwProtocol| is SCARD_PROTOCOL_ANY_OLD.
-
-In that case, the hang happens in the loop that attempts to find the
-highest bit in the |cardProtocol| value; it doesn't handle the case
-when the latter is zero:
-https://salsa.debian.org/rousseau/PCSC/-/blob/467df10d439f6d739cd48a51f2b3dd543b1a64ce/src/winscard.c#L1583
-
-P.S. Sorry if I misunderstood something and this case can never occur
-in practice.
-
-Regards,
-Maksim "
----
- src/winscard.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/winscard.c b/src/winscard.c
-index 9f24cd7..3b88554 100644
---- a/src/winscard.c
-+++ b/src/winscard.c
-@@ -1580,7 +1580,7 @@ LONG SCardTransmit(SCARDHANDLE hCard, const SCARD_IO_REQUEST *pioSendPci,
- 		unsigned long i;
- 		unsigned long prot = rContext->readerState->cardProtocol;
- 
--		for (i = 0 ; prot != 1 ; i++)
-+		for (i = 0 ; prot != 1 && i < 16; i++)
- 			prot >>= 1;
- 
- 		sSendPci.Protocol = i;
--- 
-1.8.3.1
-

0003-ATRDecodeAtr-always-initialize-the-return-values.patch

@@ -1,52 +0,0 @@
-From a706455f31178ab35f07e3e6e76bd4a35d7ef3da Mon Sep 17 00:00:00 2001
-From: Ludovic Rousseau <ludovic.rousseau@free.fr>
-Date: Sat, 8 Aug 2020 15:11:53 +0200
-Subject: [PATCH 03/13] ATRDecodeAtr: always initialize the return values
-
-Always set a value to availableProtocols and currentProtocol before any
-return in error.
-
-Thanks to Maksim Ivanov for the bug report
-"[Pcsclite-muscle] Missing checks of ATRDecodeAtr returns"
-http://lists.infradead.org/pipermail/pcsclite-muscle/2020-July/001097.html
-
-" Hello,
-
-The callers of the ATRDecodeAtr() function (SCardConnect() and
-SCardReconnect() in winscard.c) don't check its return value, which
-might potentially cause reads of uninitialized variables
-|availableProtocols| and |defaultProtocol| and unexpected side
-effects.
-
-Regards,
-Maksim "
----
- src/atrhandler.c | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/src/atrhandler.c b/src/atrhandler.c
-index 2ebc440..1e0654d 100644
---- a/src/atrhandler.c
-+++ b/src/atrhandler.c
-@@ -75,15 +75,15 @@ short ATRDecodeAtr(int *availableProtocols, int *currentProtocol,
- 		LogXxd(PCSC_LOG_DEBUG, "ATR: ", pucAtr, dwLength);
- #endif
- 
--	if (dwLength < 2)
--		return 0;	/** @retval 0 Atr must have TS and T0 */
--
- 	/*
- 	 * Zero out the bitmasks
- 	 */
- 	*availableProtocols = SCARD_PROTOCOL_UNDEFINED;
- 	*currentProtocol = SCARD_PROTOCOL_UNDEFINED;
- 
-+	if (dwLength < 2)
-+		return 0;	/** @retval 0 Atr must have TS and T0 */
-+
- 	/*
- 	 * Decode the TS byte
- 	 */
--- 
-1.8.3.1
-

0004-EHUnregisterClientForEvent-correctly-handle-EHTryToU.patch

@@ -1,36 +0,0 @@
-From 278b55a87a5f4b9bd86513f7d8f9ab7d66558602 Mon Sep 17 00:00:00 2001
-From: Ludovic Rousseau <ludovic.rousseau@free.fr>
-Date: Sat, 8 Aug 2020 17:37:40 +0200
-Subject: [PATCH 05/13] EHUnregisterClientForEvent: correctly handle
- EHTryToUnregisterClientForEvent
-
-EHTryToUnregisterClientForEvent() returns SCARD_S_SUCCESS or
-SCARD_F_INTERNAL_ERROR but never a negative value.
-
-Thanks to Valerii Zapodovnikov for the bug report
-"Code cleanup"
-https://salsa.debian.org/rousseau/PCSC/-/issues/19
-
-" https://salsa.debian.org/rousseau/PCSC/-/blob/master/src/eventhandler.c#L107
-rv < 0 is always false, because on line 94 there SCARD_F_INTERNAL_ERROR
-is ((LONG)0x80100001 and SCARD_S_SUCCESS is ((LONG)0x00000000). "
----
- src/eventhandler.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/eventhandler.c b/src/eventhandler.c
-index 932d30b..8d450d5 100644
---- a/src/eventhandler.c
-+++ b/src/eventhandler.c
-@@ -104,7 +104,7 @@ LONG EHUnregisterClientForEvent(int32_t filedes)
- {
- 	LONG rv = EHTryToUnregisterClientForEvent(filedes);
- 
--	if (rv < 0)
-+	if (rv != SCARD_S_SUCCESS)
- 		Log2(PCSC_LOG_ERROR, "Can't remove client: %d", filedes);
- 
- 	return rv;
--- 
-1.8.3.1
-

pcsc-lite.spec

@@ -1,6 +1,6 @@
 Name:           pcsc-lite
-Version:        1.9.0
+Version:        1.9.4
-Release:        3
+Release:        1
 Summary:        Middleware to access a smart card using SCard API (PC/SC)
 License:        BSD
 URL:            https://pcsclite.apdu.fr/
@@ -18,12 +18,6 @@ Recommends:     ccid
 Provides:       pcsc-lite-libs%{?_isa} pcsc-lite-libs
 Obsoletes:      pcsc-lite-libs
 
-Patch0:      0000-pcsc-lite-change-to-use-python3-for-pcsc-spy.patch
-Patch1:      0001-Do-not-possibly-lock-a-reader-if-allocating-hCard-fa.patch
-Patch2:      0002-Fix-a-hang-in-SCardTransmit.patch
-Patch3:      0003-ATRDecodeAtr-always-initialize-the-return-values.patch
-Patch4:      0004-EHUnregisterClientForEvent-correctly-handle-EHTryToU.patch
-
 %description
 PC/SC Lite is a middleware to access a smart card using SCard API (PC/SC).
 This package contains PC/SC Lite server and other utilities.
@@ -116,6 +110,9 @@ mkdir -p %{buildroot}/%{_localstatedir}/run/pcscd
 
 
 %changelog
+* Tue Nov 23 2021 yanglongkang <yanglongkang@huawei.com> - 1.9.4-1
+- update to 1.9.4
+
 * Fri Jul 30 2021 chenyanpanHW <chenyanpan@huawei.com> - 1.9.0-3
 - DESC: delete -S git from %autosetup, and delete BuildRequires git