Hello, On Tue, Feb 8, 2011 at 22:42, Douglas E. Engert <deeng...@anl.gov> wrote: > On 2/8/2011 1:29 PM, Andre Zepezauer wrote: >> >> Hello Douglas, >> >> please have a look at that picture [1]. FYI the cardmod resides on the >> same level as OpenSC.tokend does. As you can see, there is a clear >> distinction between the library 'libopensc' and the applications (shown >> at the top). >> > > Yes, cardmod would be a box next to tokend with a line to libopensc. But > the BaseCSP passed reader and card handles to cardmod. These need to be > passed to the PC/SC driver. That would be a line from the cardmod box > to the PC/SC box. That line is implemented by use_reader.
OpenSC.tokend is separate from the rest of OpenSC mostly because of two reasons: * Licensing (OpenSC.tokend is derived from APSL code and is not LGPL) * Braindead OS X specific build process (you need to have private binaries from OS X "open source" program to link a tokend). Those pieces used to be built 100% from source under the SCA umbrella (in line with the official documentation from Apple) with darwinbuild but that was a stupid and time consuming procedure. Now the necessary binaries were pre-fetched from Apple and pre-bundled by me (you can re-do the procedure if you want, the helper script is available in OpenSC.tokend git, packaged pieces for 10.5 or 10.6 weight around 40M each) and the build is simpler. Maybe things have improved even more recently and there are further improvements to be made to the build process of OpenSC.tokend, but that needs time to investigate. Volunteers are most welcome, I don't have the time to dig deep into this but I can give helpful advice as needed. Licensing with MiniDrivers is important as well, to my knowledge MS will not accept any LGPL code into the "autodiscovery" list of modules that could be put into Windows update and would auto-install the MiniDriver with Windows 7. 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, if there is a problem within a particular application, that problem >> should also be fixed within the same application. If that isn't possible >> at all, then improvements in libopensc may be considered. > > (The term application is vague. Cardmod is not the application, is is a > module under the BaseCSP. The application could be IE, login, certutil etc.) > > All of the existing applications that use OpenSC allow the reader drivers > to find reader and cards on their own. The reader drivers do the detection, > and all the reader and card communication. Correct. This is one place where practicality beats purity. The task of OpenSC is to expose the smart card to users (applications) in the most convenient way. This means as good platform integration as possible for the native users (native applications using native API-s). 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. 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 :) >> >> 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. Those deficiencies in current PC/SC code never triggered a healthy discussion when the cardmod code was commited, unfortunately. Discussion about tasks that the code in reader-pcsc.c should do, the necessary extra entry points (yes, only PC/SC, don't bother thinking about CT-API or OpenCT here) 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. Furthermore, any cardmod adjustments can be implemented and isolated with ifdef-s, 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) > 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. Cheers, Martin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
