On Feb 11, 2011, at 9:47 PM, Douglas E. Engert wrote: > On 2/11/2011 11:35 AM, Martin Paljak wrote: >> >> Didn't you include the sc_ctx_detect_readers realignment patch that removed >> it from create context to the responsibility of calling application? (will >> check and include it otherwise) >> > > No, I was leaving it up to you. (And trying to encourage Brain to say > something > more about how they were using OpenSC and needed this patch.) > > The patches I installed where independent of your patch, as the cardmod > code in reader-pcsc.c sets cardmod_ops.detect_readers = NULL; > so even if it is called nothing happens. OK
>>> libs to find the readers and cards. >> >> Who needs to call sc_ctx_detect_readers or equivalent and when. > > I would assume any application expects OpenSC and the drivers > to detect all the readers and cards. Up until cardmod that would > have been the default. (I am not sure about tokend.) > >> I don't think this should be done at context creation time. > > I agree. But where to call it? Or should it be internal to > the PC/SC driver if it has no readers, then it needs to detect them. Simple: a fresh context will have no readers without detection, detection should clean up the reader list from disconnected readers as well (needs refcounting and development) Moving the responsibility to "applications" is in the previous patch [1] >>>> Furthermore, any cardmod adjustments can be implemented and isolated >>>> with ifdef-s, >>> >>> The only #ifdef ENABLED_CARDMOD left is in ctx, and that could easily be >>> removed as it tests the app_name for "cardmod" (The cardmod/Makefile.am >>> has one to compile or not.) That test for the app_name is needed today >>> because of the way the readers are initialized, and the cardmod looks >>> like a separate driver. This could change if the mods were merged better >>> in reader-pcsc.c >> >> As you said above, "The cardmod modifications to >> reader-pcsc for the most part turn off all these features, so they don't >> get accidentally executed and cause problems.". >> >> >> #ifdef-s in reader-pcsc.c are OK to assure those limitations. >> But those ifdef-s only should exist in reader-pcsc.c, as the only reader >> driver the minidriver will know about is the pcsc driver. And to make it >> very sure, if the codebase is compiled to produce minidriver DLL, the extra >> ifdef-s will guarantee that those restrictions are enforced (actually it >> should be assured by the minidriver code that nothing gets called that would >> "confuse" reader-pcsc.c) >> > > I would still assume that the first thing a combined driver would do > would be to set a "use_provided_readers" or "cardmod_mode" flag so > "#ifdef"s are not used, but "if" statements are. > > This would allow the same build to be used for both cardmod and pkcs#11. If-s should suffice, I assume the same. Eventually #ifdef-s and a separate compile could probably allow to reduce the overall binary dll size even more. >>>> >>>> as it can be built separately from "OpenSC, the PKCS#11 >>>> and command line tools distribution". A minidriver should be >>>> distributed as a single DLL (as described in the spec), it could thus >>>> be distributed separately from the rest of OpenSC (like in some >>>> corporate environment where the only job of OpenSC minidriver is to >>>> provide the ability to authenticate with IE after the IT department >>>> has issued cards personalized with OpenSC to empolyees) >>> >>> That is an option, it could also be distributed with the opensc >>> package, as even on Windows sometimes one want to use PKCS#11. >> Sure. But unlike opensc-pkcs11.dll the minidriver dll should always be >> static and not depend on opensc.dll (or any other dll if possible) >> > > Will there be any issues with the OpenSSL, or zlib trying to make a > single DLL? What kind of issues? I don't know of any show stoppers, why? (I've not yet built with zlib though) > > What about the dependency on the opensc.conf file? Cardmod still > uses it. OpenSC should work just fine for most cases without a configuration file. There are some small things here and there that might fail but those should be handled as bugs. As a general policy, OpenSC should work out of the box without requiring the presence of a (default) configuration file and/or modifications to the default config file. opensc.conf should be used for expert tuning and occasional debugging rather than be a file an administrator (or user) should regularly edit before being able to use the software (like httpd.conf) Do you see problems with using opensc.conf in a minidriver situation? >>> As a side note, I use Thunderbird on W7. Some people like FireFox too. >>> It is a bit of a hassle, as there are two certificate stores, >>> on the same machine, and you need to register your card >>> and its CA certs with both the Microsoft cert store and the NSS. >> >> Yeah, the way Mozilla/NSS handles smart cards and different platforms was a >> "hot topic" at FOSDEM. > > Any comments on what people were saying? Main question: how to make it sucks less. And why Chrome is now a better-behaving NSS browser than Mozilla itself. [1] http://www.opensc-project.org/pipermail/opensc-devel/attachments/20110125/3ef24d98/attachment.obj -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
