On 2/11/2011 2:25 PM, Martin Paljak wrote: > > 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]
So are you going to commit that patch? > >>>>> 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) I don't know of any, just asking. > > >> >> 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? No, other then security issues. The opensc.conf and debug file could expose pins. It can also load external drivers. > >>>> 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. I wonder if it is using a newer version of NSS? > > > > [1] > http://www.opensc-project.org/pipermail/opensc-devel/attachments/20110125/3ef24d98/attachment.obj -- 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
