On 2/11/2011 11:35 AM, Martin Paljak wrote: > > On Feb 11, 2011, at 6:39 PM, Douglas E. Engert wrote: ism :) >> >> There is still Brian's issue. He says he has a CSP or is it a mini-driver >> that can use OpenSC if sc_ctc_detect_readers is not called. He still has >> not said how he does it. Brian??? > 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. > >>>>> >>>>> What are you talking about? >>>> >>>> In some of your notes you were proposing different entry points >>>> for different reasons. These might be good ideas for some >>>> future projects. One note talked about combining the original >>>> pcsc and modified copies of these routines used for cardmod, >>>> to reduce the redundent code. >>> >>> I've said this before: the way I see it, reader-*.c files translate >>> between sc_* API and the reader API that is implemented. cardmod is >>> not a reader driver, it is a set of conventions when dealing with >>> Windows winscard API, that were not "available" in the reader-pcsc.c >>> code at that time. >> >> Its more then dealing with the winscard API. The mini-driver is >> implementing a generic file structure for the card with file names like >> cardid, cardcf, cmapfile, kscNN, kxcNN and cardapps in the mscp directory. >> Its more like the PKCS#11 routines on top of PKCS#15 with a specific >> reader and card. > That's the "object translation" which is the purpose of an OpenSC "interface > driver" not the reader driver problem. > > OpenSC would "translate" two three different object worlds and three > different interfaces. From PKCS#15 to: > - PKCS#11 (slots, tokens etc) > - Tokend/Keychain/CDSA (keychains with objects and other CSSM bits and > pieces) > - MiniDriver/BaseCSP (the Microsoft view of a "smart card with files" world > as you described). > > Only Tokend and MiniDriver depend in real life on PC/SC for card access. > >>> Those deficiencies in current PC/SC code never triggered a healthy >>> discussion when the cardmod code was commited, unfortunately. >> >> The more I look at the cardmod modifications in reader-pcsc.c >> they look like they could be merged with the original code. > > SHOULD. > I will look at merging the code if that is OK. > >>> Discussion about tasks that the code in reader-pcsc.c should do, the >>> necessary extra entry points >> >> There is only one extra entry point, use_reader with 2 parameters. > Which is fine. > >>> (yes, only PC/SC, don't bother thinking >>> about CT-API or OpenCT here) >> >> I agree. In these drivers the *_use_reader = NULL; > Maybe the sc_ wrapper can be omitted somehow to make the call stack thinner. > This is not a real problem though... > > >>> or the necessary calls that should be >>> additionally done by "applications" instead of reader or libopensc >>> code (sc_detect_readers) to adopt to the requirements that would >>> satisfy all callers need to be designed. >> >> The difference with the cardmod vs any other caller of opensc is the >> PC/SC handles are provided and are being managed by the calling application. >> All the PKCS#11 applications and opensc tools expect opensc >> 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. > > >>> 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. > > >>> 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 about the dependency on the opensc.conf file? Cardmod still uses it. > >> 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. I actually have my Thunderbird profile in AFS, a shared file system, and so I can run Thunderbird on W7, XP, Solaris(32 bit big endian) or Ubuntu (32 bit little endian) and use the same files. I must be careful to only run it on one at a time, because the locking is different across windows and unix. But the databases including the cert.db is the same. Any comments on what people were saying? > >>>> Part of the problem with the mini-driver is trying to understand >>>> what Microsoft is really doing, especially without having their >>>> source code. Being able to test a modification is a big part of >>>> the development process. That is why I was asking if you have >>>> and environment to build and test any cardmod changes. >>> >>> This is where Jenkins should start to help, see my previous e-mail about it. >>> >>> Right now, the virtual machines run in my PC, which could easily host >>> a dozen of different machines, but has limited access to the internet >>> (1024K/512K). So a per-commit build with installer upload is not: >>> feasible at the moment, I've configured daily builds only. If somebody >>> has a Windows machine with better network connection, it can be used >>> to a) repeat the native build process b) provide the build result as a >>> download through opensc-project.org. The necessary environment setup >>> is quite simple: Platform SDK (500M download), Java (for running >>> Jenkins slave), CNGSDK (for cardmod headers), OpenSSL (right now the >>> slpro binary is used, but probably shall be built as well in the >>> future). The node must not be connected 24/7 to be useful. >>> >>> Information about all this will end up in OpenSC wiki eventually, >>> right now please ping me privately (or on the list) if you want hook >>> in. The ultimate goal is to be able to provide installers with >>> natively built code for every source commit. My guesstimate is that >>> this will happen in about 1 to 1.5 months. >>> >> >> I like the naively built code, but I must admit the mingw works a lot >> better then I had expected, and also builds the openssl and zlib >> as well as some other modules. > > And many other modules. Mingw works but has some limitations, like being > disconnected from the "real platform" in terms of headers and actually > present libraries or not being able to produce static binaries. Also, the > "build" build scriptto my knowledge requires re-building world all the time. > Which is OK with todays computers but somewhat annoying. > I hacked the build script, commenting out rebuilds of most things. I pointed the opensc source at a svn version and split the build_opensc into a configure and a make part. ran it once to configure, then commented out the configure Thus I could run build, and it would do the make, and packaging rather quicky. > Setting up the infrastructure to provide repeatable uploaded builds with > Jenkins is a matter of few nights of work, but unfortunately I'm overbooked > the next 7..10 days and only have occasional hours to spend. Arranging the > extra infrastructure to provide builds for every commit (vs building when > commanded by administrator) takes even more time and is not a top priority at > the moment, that's why a relaxed 1to 1.5 months seems like a realistic > timeframe for the build-per-commit solution. > I understand. What I was hopping others like François would take what is in the svn and try it. -- 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
