Menu
▾
▴
opensc-devel
|
From: Viktor T. <vik...@gm...> - 2015-03-22 10:28:40
|
Hi, I propose to prepare the next 0.15.0 release. The dedicated branch is created. Please tell if there are outstanding bugs that have to be fixed, something essential is still to be integrated into this release. Any proposals, suggestions, test results are heartily wellcome. Best regards, Viktor. |
|
From: Andreas S. <and...@ca...> - 2015-03-22 16:45:01
|
Hi Viktor, I've done a complete regression test with the SmartCard-HSM during which we discovered a broken commit. I've added pull request 399 to revert this commit and fix parameter checking. Other than that, the current master works with the SmartCard-HSM. Andreas On 03/22/2015 11:28 AM, Viktor Tarasov wrote: > Hi, > > I propose to prepare the next 0.15.0 release. The dedicated branch is created. > > Please tell if there are outstanding bugs that have to be fixed, > something essential is still to be integrated into this release. > > Any proposals, suggestions, test results are heartily wellcome. > > Best regards, > Viktor. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
|
From: Philip W. <wen...@gm...> - 2015-03-23 11:34:05
|
Hi, I will focus on testing with the IsoApplet (and possibly necessary enhancements) this week. Kind regards, Philip. On 03/22/2015 11:28 AM, Viktor Tarasov wrote: > Hi, > > I propose to prepare the next 0.15.0 release. The dedicated branch is created. > > Please tell if there are outstanding bugs that have to be fixed, > something essential is still to be integrated into this release. > > Any proposals, suggestions, test results are heartily wellcome. > > Best regards, > Viktor. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Douglas E E. <dee...@gm...> - 2015-03-25 12:35:17
|
#395 should be addressed. Either by fixing the memory leak, or by removing the two free() introduced recently that broke the code completely. Better to have a memory leak, then code that does not work at all. On 3/22/2015 5:28 AM, Viktor Tarasov wrote: > Hi, > > I propose to prepare the next 0.15.0 release. The dedicated branch is created. > > Please tell if there are outstanding bugs that have to be fixed, > something essential is still to be integrated into this release. > > Any proposals, suggestions, test results are heartily wellcome. > > Best regards, > Viktor. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Frank M. <mo...@in...> - 2015-03-25 22:55:41
|
I'd like to add #403 to the list of minor fixes, so we now have the following issues on the todo list: #395 #399 #403 -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Frank M. <mo...@in...> - 2015-03-25 23:24:01
|
I created https://github.com/OpenSC/OpenSC/issues/404 to collect all cards that are supported... On Wednesday, March 25 at 11:55PM, Frank Morgner wrote: > I'd like to add #403 to the list of minor fixes, so we now have the > following issues on the todo list: > > #395 > #399 > #403 > > -- > Frank Morgner > > Virtual Smart Card Architecture http://vsmartcard.sourceforge.net > OpenPACE http://openpace.sourceforge.net > IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Douglas E E. <dee...@gm...> - 2015-03-26 23:14:53
|
May I suggest that the git master branches of engine_pkcs11 and libp11 get released at the same time as opensc 0.15.0 On 3/25/2015 6:23 PM, Frank Morgner wrote: > I created https://github.com/OpenSC/OpenSC/issues/404 to collect all > cards that are supported... > > > On Wednesday, March 25 at 11:55PM, Frank Morgner wrote: >> I'd like to add #403 to the list of minor fixes, so we now have the >> following issues on the todo list: >> >> #395 >> #399 >> #403 >> >> -- >> Frank Morgner >> >> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net >> OpenPACE http://openpace.sourceforge.net >> IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc > > > >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Philip W. <wen...@gm...> - 2015-03-29 12:18:50
|
Hi, this lead me to discover (and test) the ECDSA enhancements of engine_pkcs11 after the last release. It shows that it behaves differently with the IsoApplet than pkcs11-tool - sending the pre-hashed data to the card/driver, which the applet can't handle due to Java Card API limitiatons. This might also be a bug of the card driver, maybe the flags are set incorrectly. I won't have time today, but I will debug this the next days. Kind regards, Philip On 03/27/2015 12:09 AM, Douglas E Engert wrote: > May I suggest that the git master branches of engine_pkcs11 and libp11 get released at the same > time as opensc 0.15.0 > > > On 3/25/2015 6:23 PM, Frank Morgner wrote: >> I created https://github.com/OpenSC/OpenSC/issues/404 to collect all >> cards that are supported... >> >> >> On Wednesday, March 25 at 11:55PM, Frank Morgner wrote: >>> I'd like to add #403 to the list of minor fixes, so we now have the >>> following issues on the todo list: >>> >>> #395 >>> #399 >>> #403 >>> >>> -- >>> Frank Morgner >>> >>> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net >>> OpenPACE http://openpace.sourceforge.net >>> IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc >> >> >> >>> ------------------------------------------------------------------------------ >>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >>> by Intel and developed in partnership with Slashdot Media, is your hub for all >>> things parallel software development, from weekly thought leadership blogs to >>> news, videos, case studies, tutorials and more. Take a look and join the >>> conversation now. http://goparallel.sourceforge.net/ >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> >> >> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > |
|
From: Douglas E E. <dee...@gm...> - 2015-03-29 20:39:54
|
On 3/29/2015 7:18 AM, Philip Wendland wrote: > Hi, > > this lead me to discover (and test) the ECDSA enhancements of > engine_pkcs11 after the last release. > > It shows that it behaves differently with the IsoApplet than pkcs11-tool > - sending the pre-hashed data to the card/driver, which the applet can't > handle due to Java Card API limitiatons. Not clear what your card is supporting, PKCS#11 2.01 and 2.20 define CKM_ECDSA and CKM_ECDSA_SHA1 Looks like 2.30 does too. SHA1 is dead and should not be used. I would assume that it should not be used with ECDSA either. > > This might also be a bug of the card driver, maybe the flags are set > incorrectly. > I won't have time today, but I will debug this the next days. > > Kind regards, > Philip > > On 03/27/2015 12:09 AM, Douglas E Engert wrote: >> May I suggest that the git master branches of engine_pkcs11 and libp11 get released at the same >> time as opensc 0.15.0 >> >> >> On 3/25/2015 6:23 PM, Frank Morgner wrote: >>> I created https://github.com/OpenSC/OpenSC/issues/404 to collect all >>> cards that are supported... >>> >>> >>> On Wednesday, March 25 at 11:55PM, Frank Morgner wrote: >>>> I'd like to add #403 to the list of minor fixes, so we now have the >>>> following issues on the todo list: >>>> >>>> #395 >>>> #399 >>>> #403 >>>> >>>> -- >>>> Frank Morgner >>>> >>>> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net >>>> OpenPACE http://openpace.sourceforge.net >>>> IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc >>> >>> >>> >>>> ------------------------------------------------------------------------------ >>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >>>> by Intel and developed in partnership with Slashdot Media, is your hub for all >>>> things parallel software development, from weekly thought leadership blogs to >>>> news, videos, case studies, tutorials and more. Take a look and join the >>>> conversation now. http://goparallel.sourceforge.net/ >>>> _______________________________________________ >>>> Opensc-devel mailing list >>>> Ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >>> by Intel and developed in partnership with Slashdot Media, is your hub for all >>> things parallel software development, from weekly thought leadership blogs to >>> news, videos, case studies, tutorials and more. Take a look and join the >>> conversation now. http://goparallel.sourceforge.net/ >>> >>> >>> >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >> > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: David W. <dw...@in...> - 2015-05-14 09:16:02
Attachments:
smime.p7s
|
On Wed, 2015-03-25 at 23:55 +0100, Frank Morgner wrote:
> I'd like to add #403 to the list of minor fixes, so we now have the
> following issues on the todo list:
>
> #395
> #399
> #403
Is this one already known?
[dwoodhou@i7 tools]$ ./pkcs11-tool -t --login
Using slot 1 with a present token (0x1)
Segmentation fault (core dumped)
Program received signal SIGSEGV, Segmentation fault.
sc_transmit_apdu (card=card@entry=0x622fb0, apdu=apdu@entry=0xffff800000002fa1)
at apdu.c:567
567 sc_detect_apdu_cse(card, apdu);
(gdb) p apdu
$1 = (sc_apdu_t *) 0xffff800000002fa1
(gdb) p *apdu
Cannot access memory at address 0xffff800000002fa1
(gdb) bt
#0 sc_transmit_apdu (card=card@entry=0x622fb0,
apdu=apdu@entry=0xffff800000002fa1) at apdu.c:567
#1 0x00007ffff7c8a30b in iso7816_pin_cmd (card=0x622fb0, data=0x7fffffffad40,
tries_left=0x0) at iso7816.c:1094
#2 0x00007ffff7c82df4 in sc_pin_cmd (card=0x622fb0, data=0x7fffffffad40,
tries_left=0x0) at sec.c:161
#3 0x00007ffff7a03469 in C_GetTokenInfo (slotID=1, pInfo=0x7fffffffd070)
at framework-pkcs15.c:500
#4 0x000000000040696e in get_token_info (slot=<optimized out>,
info=info@entry=0x7fffffffd070) at pkcs11-tool.c:2944
#5 0x0000000000406e06 in login (session=6564752, login_type=1)
at pkcs11-tool.c:1113
#6 0x000000000040301c in main (argc=<optimized out>, argv=<optimized out>)
at pkcs11-tool.c:796
[dwoodhou@i7 tools]$ LD_LIBRARY_PATH=/ssd/git/OpenSC/src/libopensc/.libs valgrind .libs/pkcs11-tool --login -t
==8491== Memcheck, a memory error detector
==8491== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8491== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==8491== Command: .libs/pkcs11-tool --login -t
==8491==
==8491== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==8491== at 0x3841A0F9CD: send (send.c:27)
==8491== by 0x3848E06E50: MessageSend (winscard_msg.c:389)
==8491== by 0x3848E06F67: MessageSendWithHeader (winscard_msg.c:328)
==8491== by 0x3848E02B56: SCardConnect (winscard_clnt.c:831)
==8491== by 0x4C5A382: pcsc_detect_readers (reader-pcsc.c:1091)
==8491== by 0x4C2EA8F: sc_ctx_detect_readers (ctx.c:634)
==8491== by 0x4C2F543: sc_context_create (ctx.c:757)
==8491== by 0x53FBC2B: C_Initialize (pkcs11-global.c:229)
==8491== by 0x402E65: main (pkcs11-tool.c:690)
==8491== Address 0xffeffec06 is on thread 1's stack
==8491== in frame #3, created by SCardConnect (winscard_clnt.c:780)
==8491==
Using slot 1 with a present token (0x1)
==8491== Conditional jump or move depends on uninitialised value(s)
==8491== at 0x4C3C1EF: iso7816_pin_cmd (iso7816.c:1084)
==8491== by 0x4C34DF3: sc_pin_cmd (sec.c:161)
==8491== by 0x540C468: C_GetTokenInfo (framework-pkcs15.c:500)
==8491== by 0x40696D: get_token_info (pkcs11-tool.c:2944)
==8491== by 0x406E05: login (pkcs11-tool.c:1113)
==8491== by 0x40301B: main (pkcs11-tool.c:796)
==8491==
==8491== Conditional jump or move depends on uninitialised value(s)
==8491== at 0x4C3F9BD: sc_transmit_apdu (apdu.c:560)
==8491== by 0x4C3C30A: iso7816_pin_cmd (iso7816.c:1094)
==8491== by 0x4C34DF3: sc_pin_cmd (sec.c:161)
==8491== by 0x540C468: C_GetTokenInfo (framework-pkcs15.c:500)
==8491== by 0x40696D: get_token_info (pkcs11-tool.c:2944)
==8491== by 0x406E05: login (pkcs11-tool.c:1113)
==8491== by 0x40301B: main (pkcs11-tool.c:796)
==8491==
==8491== Use of uninitialised value of size 8
==8491== at 0x4C3F9F2: sc_detect_apdu_cse (apdu.c:363)
==8491== by 0x4C3F9F2: sc_transmit_apdu (apdu.c:567)
==8491== by 0x4C3C30A: iso7816_pin_cmd (iso7816.c:1094)
==8491== by 0x4C34DF3: sc_pin_cmd (sec.c:161)
==8491== by 0x540C468: C_GetTokenInfo (framework-pkcs15.c:500)
==8491== by 0x40696D: get_token_info (pkcs11-tool.c:2944)
==8491== by 0x406E05: login (pkcs11-tool.c:1113)
==8491== by 0x40301B: main (pkcs11-tool.c:796)
--
dwmw2
|
|
From: David W. <dw...@in...> - 2015-05-14 10:47:56
Attachments:
smime.p7s
|
On Thu, 2015-05-14 at 10:15 +0100, David Woodhouse wrote: > > Is this one already known? > > [dwoodhou@i7 tools]$ ./pkcs11-tool -t --login > Using slot 1 with a present token (0x1) > Segmentation fault (core dumped) > Program received signal SIGSEGV, Segmentation fault. Further investigation shows this is actually caused by using the *installed* version of opensc-pkcs11.so and not the one in the build tree. The size of struct sc_pin_cmd_pin changed, and thus we are no longer binary-compatible with the original libopensc.so.3 — so using the installed (0.14.0) opensc-pkcs11.so against the libopensc in the build tree causes this crash. Don't we need an soname bump following commit 5757d82cc? And also, now that the --module option to pkcs11-tool is optional, shouldn't it automatically use the version in the build tree, when run from the build tree? Normally we expect that kind of thing to be entirely self-contained, setting rpaths or LD_LIBRARY_PATH as appropriate so that a test in the build tree doesn't end up using a mixture of old and new. That isn't working for the DEFAULT_PKCS11_PROVIDER, it seems. And in fact it isn't looking in /usr/lib64/pkcs11/ for modules *either*, On this system that's where they live... -- dwmw2 |
|
From: Viktor T. <vik...@gm...> - 2015-05-11 16:09:52
|
Hi, I would like to finalize the next release during the upcoming weekend, the main awaited feature - update of minidriver - is merged into master and release branches. It's still time to fix the outstanding bugs or to attach the pending issues to the departing train. Tests of current 'master' or 'O.15.0' branch are heartily welcomed, especially the minidriver -- smartcard logon, PIN management. Best regards, Viktor. On 03/22/2015 11:28 AM, Vikt, or Tarasov wrote: > Hi, > > I propose to prepare the next 0.15.0 release. The dedicated branch is created. > > Please tell if there are outstanding bugs that have to be fixed, > something essential is still to be integrated into this release. > > Any proposals, suggestions, test results are heartily wellcome. > > Best regards, > Viktor. > |
|
From: David W. <dw...@in...> - 2015-05-11 16:28:51
Attachments:
smime.p7s
|
On Mon, 2015-05-11 at 18:09 +0200, Viktor Tarasov wrote: > I would like to finalize the next release during the upcoming weekend > , > the main awaited feature - update of minidriver - is merged into > master and release branches. > > It's still time to fix the outstanding bugs or to attach the pending > issues to the departing train. It would be good to fix the breakage with calling C_Initialize() in the child after fork, which prevents OpenSC from working correctly when used with OpenVPN: http://sourceforge.net/p/opensc/mailman/message/34086897/ -- dwmw2 |
|
From: Frank M. <mo...@in...> - 2015-05-12 09:43:51
|
On Monday, May 11 at 05:28PM, David Woodhouse wrote: > On Mon, 2015-05-11 at 18:09 +0200, Viktor Tarasov wrote: > > I would like to finalize the next release during the upcoming weekend > > , > > the main awaited feature - update of minidriver - is merged into > > master and release branches. > > > > It's still time to fix the outstanding bugs or to attach the pending > > issues to the departing train. > > It would be good to fix the breakage with calling C_Initialize() in the > child after fork, which prevents OpenSC from working correctly when used > with OpenVPN: http://sourceforge.net/p/opensc/mailman/message/34086897/ Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ? As far as I can see from the github issue, #333 is a problem in Apple's PC/SC implementation Also, please open a PR with your example code on github to get feedback. Then this issue doesn't lost in some mail archive. -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: David W. <dw...@in...> - 2015-05-12 14:29:49
Attachments:
smime.p7s
|
On Tue, 2015-05-12 at 11:43 +0200, Frank Morgner wrote: > > Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ;? It's closely related, at least. It all stems from the recommendation in the PKCS#11 Usage Guide that a process should call C_Initialize() on loaded modules immediately after forking. > As far as I can see from the github issue, #333 is a problem in > Apple's PC/SC implementation I'm not entirely sure where the finger should be pointed. Quite frankly, it would be better just not to make the pointless call to C_Initialize() when *all* we are going to do after forking is exec something else. I actually have a cheap hack to 'fix' the problem in OpenVPN just by using vfork() instead of fork(), so the problematic pthread_atfork() handler doesn't run :) OpenSC is potentially implicated here, because after a fork it is confusing PC/SC by continuing to let both parent and child talk to pcscd over the same RPC mechanism. Or maybe PC/SC isn't "confused" per se — maybe the child tells it to power down the card, and the parent then continues to try to use it? In the OSX case shown in #333 it seem OSX has a different RPC mechanism for talking to PC/SC than Linux, and when OpenSC misuses the parent's connection from the child there's actually a crash in the RPC library. That crash certainly shouldn't happen, and looks like a PC/SC bug. But I think it's still really an OpenSC issue. > Also, please open a PR with your example code on github to get feedback. > Then this issue doesn't lost in some mail archive. I've updated #333 with a reference to the test case and noted that it occurs on Linux too. -- dwmw |
|
From: Ludovic R. <lud...@gm...> - 2015-05-12 19:28:28
|
Hello, 2015-05-12 16:29 GMT+02:00 David Woodhouse <dw...@in...>: > On Tue, 2015-05-12 at 11:43 +0200, Frank Morgner wrote: >> >> Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ;? > > > It's closely related, at least. > > It all stems from the recommendation in the PKCS#11 Usage Guide that a > process should call C_Initialize() on loaded modules immediately after > forking. > >> As far as I can see from the github issue, #333 is a problem in >> Apple's PC/SC implementation > > I'm not entirely sure where the finger should be pointed. Quite > frankly, it would be better just not to make the pointless call to > C_Initialize() when *all* we are going to do after forking is exec > something else. I actually have a cheap hack to 'fix' the problem in > OpenVPN just by using vfork() instead of fork(), so the problematic > pthread_atfork() handler doesn't run :) > > OpenSC is potentially implicated here, because after a fork it is > confusing PC/SC by continuing to let both parent and child talk to > pcscd over the same RPC mechanism. Or maybe PC/SC isn't "confused" per > se — maybe the child tells it to power down the card, and the parent > then continues to try to use it? I have re-read your logs at http://david.woodhou.se/pcsc-debug.txt What happens (if I interpret the logs correctly) is that: 1- the application is creating a PC/SC context at line 142 00000322 winscard_svc.c:353:ContextThread() Received command: ESTABLISH_CONTEXT from client 14 The client is identified as client 14 on the pcscd side. 2- the context is used 3- the context is released at line 816 00000108 winscard_svc.c:353:ContextThread() Received command: RELEASE_CONTEXT from client 14 00000009 winscard.c:227:SCardReleaseContext() Releasing Context: 0x3FA91BB 00000004 winscard_svc.c:461:ContextThread() RELEASE_CONTEXT rv=0x0 for client 14 4- the context is reused at line 864 00021883 winscard_svc.c:353:ContextThread() Received command: CMD_GET_READERS_STATE from client 14 00000033 winscard_svc.c:353:ContextThread() Received command: CMD_GET_READERS_STATE from client 14 00000096 winscard_svc.c:353:ContextThread() Received command: CMD_GET_READERS_STATE from client 14 00000052 winscard_svc.c:353:ContextThread() Received command: CMD_GET_READERS_STATE from client 14 00000022 winscard_svc.c:353:ContextThread() Received command: STATUS from client 14 00000007 winscard_svc.c:944:MSGCheckHandleAssociation() Invalidated handle What may happen is that the process is forked between steps 2 and 3. Both processes (father and son) share the same socket connection to pcscd. They are both identified as client 14. One process releases the context while the other process wants to continue to use it. In your patch at http://sourceforge.net/p/opensc/mailman/message/34086897/ you write: + /* We cannot touch the PC/SC context since it + * belongs to the parent process. FIXME: For now + * just leak it */ + context = NULL; This is not a leak. With pcsc-lite nothing is allocated on the client side. So after a fork no resource is duplicated (except an open file descriptor). So it is fine to just ignore a PC/SC context in one of the two processes after a fork. It is NOT fine to release a PC/SC context in one process and continue to use it in the other process. pcsc-lite had different versions of code to manage fork() in the client library. https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=b4d935a73e84b899dbf63bc97bca0c50c9b84f5b https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=76d1226ca6443c5ce2b3564369ed97ac9dbb9acb https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=2a8bd7a04bedcf99f8d8214b2ecbf8f0ef268c6f https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=a6b3ab6d44f5f8768b6ddb55c9aeb2ff3bd78578 1. Maybe I should reuse the version found in https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=2a8bd7a04bedcf99f8d8214b2ecbf8f0ef268c6f 2. Or maybe the developer knows what he is doing and PC/SC should not automatically invalidate handles in the son process. What do you prefer? I am afraid the PC/SC specification have not documented what should happen after a fork(). Windows has nothing equivalent to fork(). So the "do like Windows" will not help pcsc-lite. > In the OSX case shown in #333 it seem OSX has a different RPC > mechanism for talking to PC/SC than Linux, and when OpenSC misuses the > parent's connection from the child there's actually a crash in the RPC > library. > > That crash certainly shouldn't happen, and looks like a PC/SC bug. Crashing is not the correct way to manage the fork :-) > But I think it's still really an OpenSC issue. > >> Also, please open a PR with your example code on github to get feedback. >> Then this issue doesn't lost in some mail archive. > > I've updated #333 with a reference to the test case and noted that it > occurs on Linux too. I think your patch in http://sourceforge.net/p/opensc/mailman/message/34086897/ is a correct way to solve the problem (on the PC/SC side). Regards, -- Dr. Ludovic Rousseau |
|
From: David W. <dw...@in...> - 2015-05-13 13:04:04
Attachments:
smime.p7s
|
On Tue, 2015-05-12 at 21:28 +0200, Ludovic Rousseau wrote: > What may happen is that the process is forked between steps 2 and 3. > Both processes (father and son) share the same socket connection to > pcscd. They are both identified as client 14. > > One process releases the context while the other process wants to > continue to use it. Right. That's close enough to what I had understood that I'm going to pretend I was correct :) > In your patch at > http://sourceforge.net/p/opensc/mailman/message/34086897/ you write: > + /* We cannot touch the PC/SC context since it > + * belongs to the parent process. FIXME: For now > + * just leak it */ > + context = NULL; > > This is not a leak. With pcsc-lite nothing is allocated on the client > side. The difference between the code I add, and the existing call to C_Finalize() that it replaces, is partly that the new version does not make the call to sc_release_context(). The penultimate line of sc_release_context(), in src/libopensc/ctx.c, is 'free(ctx)'. We are not freeing that memory. That's what I meant when I said it was a 'leak'. However, I'm not sure we care. After we fork, there are a *lot* of other data structures left lying around that are no longer reachable. And probably stacks of other threads in the original parent, and other stuff. I'm not going to lose sleep over it. > So after a fork no resource is duplicated (except an open file > descriptor). An open file descriptor which we happily pass on to whatever is executed by the child process. We should open our file descriptors with O_CLOEXEC, but that's a somewhat orthogonal issue. > So it is fine to just ignore a PC/SC context in one of the two > processes after a fork. > It is NOT fine to release a PC/SC context in one process and continue > to use it in the other process. Right. You can use it in *one* of the two processes after a fork. It doesn't have to be the *parent* process. In the PKCS#11 case it isn't "one of the two processes" that may continue to use an established context. It is only the parent. At least according to the non-normative Usage Guide. Right there in §2.5.2 where it basically *tells* you to violate the POSIX restrictions on what you can do in the child after forking from a multi-threaded process :) Unless it's absolutely necessary, I don't think PC/SC should impose those same semantics — I think "one of the two" is the better answer. > 1. Maybe I should reuse the version found in > https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=2a8bd7a0 > 2. Or maybe the developer knows what he is doing and PC/SC should not > automatically invalidate handles in the son process. > What do you prefer? I think what I just said translates to preferring the latter of these. > > That crash certainly shouldn't happen, and looks like a PC/SC bug. > > Crashing is not the correct way to manage the fork :-) Hey, it leaves you with only one process and thus no contention about which one owns the context :) > I think your patch in > http://sourceforge.net/p/opensc/mailman/message/34086897/ is a > correct way to solve the problem (on the PC/SC side). On the OpenSC side, you mean? -- David Woodhouse Open Source Technology Centre Dav...@in... Intel Corporation |
|
From: Douglas E E. <dee...@gm...> - 2015-05-13 10:42:09
|
I would like to see "PIV - read just length of object to get size" #462 included in 0.15.0. I see it is in master as: https://github.com/OpenSC/OpenSC/commit/c7af08c68a5bb3e753b008822e947d52016266c0 On 5/11/2015 11:09 AM, Viktor Tarasov wrote: > Hi, > > I would like to finalize the next release during the upcoming weekend, > the main awaited feature - update of minidriver - is merged into master and release branches. > > It's still time to fix the outstanding bugs or to attach the pending issues to the departing train. > > Tests of current 'master' or 'O.15.0' branch are heartily welcomed, > especially the minidriver -- smartcard logon, PIN management. > > Best regards, > Viktor. > > > > On 03/22/2015 11:28 AM, Vikt, > > or Tarasov wrote: >> Hi, >> >> I propose to prepare the next 0.15.0 release. The dedicated branch is created. >> >> Please tell if there are outstanding bugs that have to be fixed, >> something essential is still to be integrated into this release. >> >> Any proposals, suggestions, test results are heartily wellcome. >> >> Best regards, >> Viktor. >> > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > . > -- Douglas E. Engert <DEE...@gm...> |
|
From: Viktor T. <vik...@gm...> - 2015-05-16 21:18:21
|
Hi, release 0.15.0 is published, https://sourceforge.net/projects/opensc/files/OpenSC/opensc-0.15.0/ https://opensc.fr/jenkins/view/OpenSC-release/ https://github.com/OpenSC/OpenSC/releases/tag/0.15.0 Thank you for your contributions, tests, ideas, discussions. Best regards, Viktor. On 03/22/2015 05:44 PM, Andreas Schwier wrote: > Hi Viktor, > > I've done a complete regression test with the SmartCard-HSM during which > we discovered a broken commit. > > I've added pull request 399 to revert this commit and fix parameter > checking. > > Other than that, the current master works with the SmartCard-HSM. > > Andreas > > On 03/22/2015 11:28 AM, Viktor Tarasov wrote: >> Hi, >> >> I propose to prepare the next 0.15.0 release. The dedicated branch is created. >> >> Please tell if there are outstanding bugs that have to be fixed, >> something essential is still to be integrated into this release. >> >> Any proposals, suggestions, test results are heartily wellcome. >> >> Best regards, >> Viktor. >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > |
|
From: David W. <dw...@in...> - 2015-05-17 07:42:05
|
On Sat, 2015-05-16 at 23:17 +0200, Viktor Tarasov wrote: > release 0.15.0 is published, Um,... really? As discussed in ticket #468 this version of libopensc.so.3 is binary-incompatible with the libopensc.so.3 from previous OpenSC releases. So anything linked against it may just crash on updating to 0.15.0. And it still doesn't seem to work with OpenVPN because of issue #333 (which affects all platforms except Windows, I believe). We merged a *test* case for that bug, but AFAICT didn't actually fix the bug. (I say both those things looking at the commit logs but without actually re-testing. I'm a little busy right now but I'd tried to make sure those bugs were both known so that the release didn't happen without them fixed...) Should we be looking to do a 0.15.1 release within the next few days with those addressed? -- dwmw2 |
|
From: Douglas E E. <dee...@gm...> - 2015-05-17 12:57:22
|
On 5/17/2015 2:41 AM, David Woodhouse wrote: > On Sat, 2015-05-16 at 23:17 +0200, Viktor Tarasov wrote: >> release 0.15.0 is published, > > Um,... really? > > As discussed in ticket #468 this version of libopensc.so.3 is > binary-incompatible with the libopensc.so.3 from previous OpenSC > releases. So anything linked against it may just crash on updating to > 0.15.0. > > And it still doesn't seem to work with OpenVPN because of issue #333 > (which affects all platforms except Windows, I believe). We merged a > *test* case for that bug, but AFAICT didn't actually fix the bug. > > (I say both those things looking at the commit logs but without actually > re-testing. I'm a little busy right now but I'd tried to make sure those > bugs were both known so that the release didn't happen without them > fixed...) > > Should we be looking to do a 0.15.1 release within the next few days > with those addressed? I agree. In the past we had pre-releases and release candidates. This time we have jumped over any release candidate (and the change to test it) and now need a 0.15.1. #git tag -l 0.12.2 0.12.2-rc1 0.13.0 0.13.0pre1 0.13.0rc1 0.14.0 0.14.0rc2 0.14.0rtm 0.15.0 maintainer-pgp-pub v0.12.2 v0.15.0-pre1 v0.15.0-pre2 v0.15.0-pre3 > -- Douglas E. Engert <DEE...@gm...> |
|
From: Viktor T. <vik...@gm...> - 2015-05-18 07:29:44
|
On 05/17/2015 09:41 AM, David Woodhouse wrote: > On Sat, 2015-05-16 at 23:17 +0200, Viktor Tarasov wrote: >> release 0.15.0 is published, > Um,... really? > > As discussed in ticket #468 this version of libopensc.so.3 is > binary-incompatible with the libopensc.so.3 from previous OpenSC > releases. So anything linked against it may just crash on updating to > 0.15.0. For me the libopensc.so was always an internal OpenSC library. Maybe I'm missing something. > And it still doesn't seem to work with OpenVPN because of issue #333 > (which affects all platforms except Windows, I believe). We merged a > *test* case for that bug, but AFAICT didn't actually fix the bug. > > (I say both those things looking at the commit logs but without actually > re-testing. I'm a little busy right now but I'd tried to make sure those > bugs were both known so that the release didn't happen without them > fixed...) > > Should we be looking to do a 0.15.1 release within the next few days > with those addressed? Yes, we'll be looking for release 0.15.1 . |
|
From: David W. <dw...@in...> - 2015-05-18 10:52:29
Attachments:
smime.p7s
|
On Mon, 2015-05-18 at 09:29 +0200, Viktor Tarasov wrote:
>
> > As discussed in ticket #468 this version of libopensc.so.3 is
> > binary-incompatible with the libopensc.so.3 from previous OpenSC
> > releases. So anything linked against it may just crash on updating to
> > 0.15.0.
>
> For me the libopensc.so was always an internal OpenSC library.
> Maybe I'm missing something.
In that case, perhaps all we should do is make it stop *looking* like
it's a "proper" shared library with a coherently-managed ABI. If you
ever look at *anything* with an soname of 'libfoo.so.3' you're going to
be inclined to believe that the soname is actually meaningful. If it
ends '.so.0' then you might be more careful.
If we do this...
diff --git a/src/libopensc/Makefile.am b/src/libopensc/Makefile.am
index 1d42b0d..a0fc0e4 100644
--- a/src/libopensc/Makefile.am
+++ b/src/libopensc/Makefile.am
@@ -64,7 +64,7 @@ if WIN32
libopensc_la_LIBADD += -lws2_32
endif
libopensc_la_LDFLAGS = $(AM_LDFLAGS) \
- -version-info @OPENSC_LT_CURRENT@:@OPENSC_LT_REVISION@:@OPENSC_LT_AGE@ \
+ -release @PACKAGE_VERSION@ \
-export-symbols "$(srcdir)/libopensc.exports" \
-no-undefined
... then we end up with 'libopensc-0.15.0.so' which seems somewhat
clearer.
It does still crash when I run 'pkcs11-tool -t -l' from the build
directory, however. Although /usr/lib64/pkcs11/opensc-pkcs11.so now
does *load* the old /usr/lib64/libopensc.so.3, it still doesn't *use*
it because it uses functions from the new libopensc-0.15.0.so instead.
To fix *that* we'd want symbol versioning.
But perhaps we should just fix the 'run from build tree' case for
pkcs11-tool instead, so it's not using opensc-pkcs11.so from the
installed system?
--
David Woodhouse Open Source Technology Centre
Dav...@in... Intel Corporation
|
|
From: Viktor T. <vik...@gm...> - 2015-05-18 11:38:23
|
On 05/18/2015 12:52 PM, David Woodhouse wrote: > On Mon, 2015-05-18 at 09:29 +0200, Viktor Tarasov wrote: >>> As discussed in ticket #468 this version of libopensc.so.3 is >>> binary-incompatible with the libopensc.so.3 from previous OpenSC >>> releases. So anything linked against it may just crash on updating to >>> 0.15.0. >> For me the libopensc.so was always an internal OpenSC library. >> Maybe I'm missing something. > In that case, perhaps all we should do is make it stop *looking* like > it's a "proper" shared library with a coherently-managed ABI. If you > ever look at *anything* with an soname of 'libfoo.so.3' you're going to > be inclined to believe that the soname is actually meaningful. If it > ends '.so.0' then you might be more careful. > > If we do this... > > diff --git a/src/libopensc/Makefile.am b/src/libopensc/Makefile.am > index 1d42b0d..a0fc0e4 100644 > --- a/src/libopensc/Makefile.am > +++ b/src/libopensc/Makefile.am > @@ -64,7 +64,7 @@ if WIN32 > libopensc_la_LIBADD += -lws2_32 > endif > libopensc_la_LDFLAGS = $(AM_LDFLAGS) \ > - -version-info @OPENSC_LT_CURRENT@:@OPENSC_LT_REVISION@:@OPENSC_LT_AGE@ \ > + -release @PACKAGE_VERSION@ \ > -export-symbols "$(srcdir)/libopensc.exports" \ > -no-undefined > > ... then we end up with 'libopensc-0.15.0.so' which seems somewhat > clearer. > > It does still crash when I run 'pkcs11-tool -t -l' from the build > directory, however. Although /usr/lib64/pkcs11/opensc-pkcs11.so now > does *load* the old /usr/lib64/libopensc.so.3, it still doesn't *use* > it because it uses functions from the new libopensc-0.15.0.so instead. I have not seen this with opensc-pkcs11 and libopensc.so from the same revision. > To fix *that* we'd want symbol versioning. > > But perhaps we should just fix the 'run from build tree' case for > pkcs11-tool instead, so it's not using opensc-pkcs11.so from the > installed system? You can use pkcs11-tool with the "--module" argument. |
|
From: David W. <dw...@in...> - 2015-05-18 11:45:05
Attachments:
smime.p7s
|
On Mon, 2015-05-18 at 13:38 +0200, Viktor Tarasov wrote: > > It does still crash when I run 'pkcs11-tool -t -l' from the build > > directory, however. Although /usr/lib64/pkcs11/opensc-pkcs11.so now > > does *load* the old /usr/lib64/libopensc.so.3, it still doesn't *use* > > it because it uses functions from the new libopensc-0.15.0.so instead. > > I have not seen this with opensc-pkcs11 and libopensc.so from the > same revision. Right. It's only when the pkcs11-tool in the build tree is picking up opensc-pkcs11.so from the installed system, that we get the mixture. Normally, we expect that if we run a program from its build tree, libtool magically makes things work for us — it sets LD_LIBRARY_PATH and does whatever else is needed to ensure we are only running the code from the build tree. And pkcs11-tool itself *was* picking up the version of libopensc.so.3 from ../libopensc/.libs, instead of the one in /usr/lib64. But in the case of the module it *loads*, that isn't working. Yes, I can supply a --module argument which explicitly points to ../pkcs11/.libs/opensc-pkcs11.so. But if we're making the --module argument optional because we want it to Do The Right Thing without having to be told... then shouldn't we actually make it do the right thing? :) -- dwmw2 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X