On Feb 11, 2011, at 6:39 PM, Douglas E. Engert wrote: >> Platform adapters should be "core" of OpenSC. How they are bundled in >> terms of source packages or distributed as binaries is a different >> story. But conceptually they are "part of OpenSC", not "external >> applications". > > So based on my comments above, cardmod is more of a "core" routine, > exposing the Microsoft CNG API rather then the PKCS#11 API.
Yes. >> >> libopensc is not set in stone, it does things that could be done >> differently and the only reason why this is not yet done is legacy. >> Legacy like mostly unused multi-reader-driver-framework. > > Maybe this is the way cardmod should have been implemented? What made sense in 2003 might not make much sense today. Seriously - for "consumer" applications, CT-API and OpenCT don't make almost any sense these days. Going through mud to achieve runtime multiple reader driver support is just not worth it. But the necessary code abstractions and indirections in libopensc still remain, for a while. Which way? I think the current modification are the most appropriate ones, that's exactly how it should be done IMHO. >> Adapting to >> requirements and external restrictions is necessary. Unlike Linux, we >> can't affect how MSFT or AAPL creates their frameworks and >> applications, we must adapt. Taking into account the amount of Windows >> installations out there it is a very good reason to adjust libopensc >> to real life. >> >> It has been a healthy discussion about minidrivers and necessary PC/SC >> adjustments this far, much better for the overall health of OpenSC >> than "we need a flag to omit some internal calls" approach or using >> registry as a function parameter passing mechanism :) > > 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) >>>> >>>> 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. >> 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 don't think this should be done at context creation time. >> 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) >> 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) > 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. >>> 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. 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. -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
