Re: [opensc-devel] OpenSC in multi-thread
On 09/09/2011 21:22, Douglas E. Engert wrote: One possible way would be to turn off some drivers in the opensc.conf file. Comments and an OpenSC web page would say how to turn it back on, and how to request that it not be dropped. The only way that works: break it in a way that requires user intervention. When in office you don't exactly know who is using some service, disable it and listen to complaints :) If (after some time) nobody complains, then nobody is using it and you can remove. Maybe that code could rot for about a year before being removed. Better if a page with instruction on how to reenable it is created FIRST, then the drivers get disabled only when it have been indexed by search engines. Comments in config file should tell packagers *not* to reenable those drivers by default... If some1 is still using those drivers, it *must* be considered a regression. Just my .02 BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
Hello, Le 09/09/2011 09:23, Martin Paljak a écrit : On 31/08/11 20:01, Viktor Tarasov wrote: during the tests of minidriver on Windows Vista there was a problem related to the using of OpenSC in multi-threads. SC context create/release are not thread safe -- they allocate/release memory referenced by the pointers fromthe static 'struct sc_card_driver'. (It concerns also, if present, load/unload of dynamic card driver.) https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/ctx.c#L749 Static 'struct sc_card_driver' is present in each card-xx. Currently, in minidriver-write-mode branch, there is a temporary hack, but I think that this problem has to be resolved on the OpenSC side. For example to introduce reference counter into 'sc_card_driver' and use it in the sc-context functions. If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. For minidriver we need to dump out programmatically ATR tables anyway, to embed that in the installer. This also. But in my case I need to check the card specific opensc configuration -- that's where from this problem appeared. What would you say? Do you know other places in the OpenSC code, that needs to be revisited from the thread safe point of view? For PKCS#11 it would be nice to remove the global lock of *all* operations and introduce a slot (or internally, a reader based) lock instead, so that multiple cards could be used simultaneously. But that's a minor thing. Reasonable. Will be keeping it in mind. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
On Fri, Sep 9, 2011 at 10:39, Viktor Tarasov viktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
Le 09/09/2011 10:09, Martin Paljak a écrit : On Fri, Sep 9, 2011 at 10:39, Viktor Tarasovviktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Fine, and to continue this movement, could we envisage the abandon of support of the obsolete cards ? Example, 'oberthur' driver supports the old v.2.xx of the 'AuthentIC' PKI applet with the proprietary file system. This card is not more produced. The new 3.2 version of this applet, compatible with PKCS#15, is actually supported by 'authentic' card driver. Best, Martin Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
On 09/09/11 11:32, Viktor Tarasov wrote: Le 09/09/2011 10:09, Martin Paljak a écrit : On Fri, Sep 9, 2011 at 10:39, Viktor Tarasovviktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Fine, and to continue this movement, could we envisage the abandon of support of the obsolete cards ? As you are also the original code author, you should be the best to judge what is relevant and what not. Example, 'oberthur' driver supports the old v.2.xx of the 'AuthentIC' PKI applet with the proprietary file system. This card is not more produced. The new 3.2 version of this applet, compatible with PKCS#15, is actually supported by 'authentic' card driver. If there are cards out there and there is not much needed to maintain the current driver as a working entity, I would not rush to remove it ASAP. Maybe a forward notice would do good and the code can rotten there with the intent of being removed in X months ? Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
Le 09/09/2011 11:22, Martin Paljak a écrit : On 09/09/11 11:32, Viktor Tarasov wrote: Le 09/09/2011 10:09, Martin Paljak a écrit : On Fri, Sep 9, 2011 at 10:39, Viktor Tarasovviktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Fine, and to continue this movement, could we envisage the abandon of support of the obsolete cards ? As you are also the original code author, you should be the best to judge what is relevant and what not. Finally I roll back this proposal -- there has been a voice in defense of the 'oberthur' driver. Example, 'oberthur' driver supports the old v.2.xx of the 'AuthentIC' PKI applet with the proprietary file system. This card is not more produced. The new 3.2 version of this applet, compatible with PKCS#15, is actually supported by 'authentic' card driver. If there are cards out there and there is not much needed to maintain the current driver as a working entity, I would not rush to remove it ASAP. Maybe a forward notice would do good and the code can rotten there with the intent of being removed in X months ? Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
On 9/9/2011 4:22 AM, Martin Paljak wrote: On 09/09/11 11:32, Viktor Tarasov wrote: Le 09/09/2011 10:09, Martin Paljak a écrit : On Fri, Sep 9, 2011 at 10:39, Viktor Tarasovviktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Fine, and to continue this movement, could we envisage the abandon of support of the obsolete cards ? As you are also the original code author, you should be the best to judge what is relevant and what not. Example, 'oberthur' driver supports the old v.2.xx of the 'AuthentIC' PKI applet with the proprietary file system. This card is not more produced. The new 3.2 version of this applet, compatible with PKCS#15, is actually supported by 'authentic' card driver. If there are cards out there and there is not much needed to maintain the current driver as a working entity, I would not rush to remove it ASAP. Maybe a forward notice would do good and the code can rotten there with the intent of being removed in X months ? There may be (or not) people who are using one of these old drivers who are not developers, or on any OpenSC list. Is there any way to find out from the user community if a driver is still being used? Anyway to notify a user that a driver may be dropped? One possible way would be to turn off some drivers in the opensc.conf file. Comments and an OpenSC web page would say how to turn it back on, and how to request that it not be dropped. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
