On Friday 06 February 2009 10:33:53 Ludovic Rousseau wrote: > 2009/2/6 Alon Bar-Lev <alon.bar...@gmail.com>: > > I did not require much of Ludovic time. > > After I implement the framework and the difficult PC/SC verbs: > > SCardBeginTransaction > > SCardEndTransaction > > SCardGetStatusChange > > SCardCancel > > SCardTransmit > > We complete together the rest of the interface. > > > > I also committed into writing the first reader driver that would > > be IFD Handler API, which will load and use the current CCID driver. > > OK. Let us see what you propose.
Reading the thread and some off list messages I got from Andreas, it looks like I created more noise that I intended. My intentions were sincere, proving a better solution for users and merging our resources. I outlined the high level design a few times, first off-list discussion with Ludovic, then publicly. The mission is to separate between the application API and the reader driver interface, based on the OpenCT driver model, which is single threaded, one process per reader, none daemon model. If people think it is over engineered or I am going to re-invent the wheel, please come forward now. Also I discovered for the first time that at least Andreas has some criticism to some of the work I've committed into OpenSC projects. Maybe I truly in a minority and damaging the project. I appreciate users opinion about the necessity of the changes I've done since I wished to actually use OpenSC implementation. All changes were performed in a separate branch before merge. I asked for comments. Needless to say I almost never got any comment. 1. PKCS#11 fork() compliant The PKCS#11 specification specify exactly how a module should behave after fork() call. OpenSC's PKCS#11 implementation did not follow the specification. Also pcsc-lite did not support fork either, as in Windows the problem does not exist. The fix was within the OpenSC PKCS#11 module and pcsc-lite. 2. PKCS#11 v2.20 plug and play. PKCS#11 2.20 added plug and play support to the specification, until then PKCS#11 application should have reloaded all modules in order to detect new readers. The plug and play is required especially for crypto tokens (reader+card), as they reader is plugged/unplugged every card insert/remove. Example: You cannot use Mozilla Firefox with CCID compliant token without this feature. The plug and play is workable, but far from being perfect. 3 OpenSC PKCS#15 data object label support OpenSC's PKCS#15 utility did not set the PKCS#11 CKA_LABEL field for data objects. The change was within the utilities in order to allow specifying the label for data object and allow delete based on this object. 4. The new and synchronized build system for all projects. The build system of OpenSC was a mess. It did not allow explicit dependency enforcement, it had a lot of duplicates and unclean autoconf/automake/libtool usage. I rewrote the build system and sync it between all of OpenSC project for simple maintenance. 5. The mingw build. The OpenSC project maintained two separate build systems, one for POSIX and one for Windows. The Windows build was unmaintained and forced using Microsoft tools. This caused developers not to check even compilation under Windows, and resulted in many compilation issues existed for Windows. autoconf/automake/libtool support Windows build using mingw, so I made the necessary changes in order to produce Windows binaries using the maintained build system. Also allowed cross compile to Windows so that every developer can use free tools and his own system in order to at least check that the code compiles fine on Windows. 6. The support of win64. The work on mingw allowed supporting win64 without any change except of incompatibility between pcsc-lite and win64 sizeof(long). 7. OpenCT none root. I believe security solutions should run in least privileged mode. Current hotplug services support this easily. Apparently there are people here that think that least privileged mode is more dangerous than running all under root... I cannot say I understand their arguments. 8. OpenCT linux coldplug without usbfs. The only requirement for libusb and usbfs in OpenCT was for the cold plug process on Linux. I wrote a simple replacement using sysfs and dropped the dependency. Now OpenCT can be run without usbfs. 9. OpenCT event support. OpenCT polled the existence of devices, it also polled the existence of card. There was a bug in Linux that prevented detecting usb device unplug, I've worked with upstream in order to fix it, and it was committed in linux-2.6.27.14, linux-2.6.28.3. I also learned from Ludovic CCID driver about the CCID card status change notification, and together with the help of Chaskiel M Grundman, we made the OpenCT CCID driver consume no CPU if reader support events. 10. OpenCT mdev/udev fixups. Minor fixups to keep OpenCT work with latest versions. Ludovic, I feel like you are forced into a process you do not wish to participate. It is obvious that the spirit of cooperation was not there. Let's ignore the recent postings, and assume that after I outlined the high level design, you said that it looks reasonable, and we start to set the goals, I need your help in refine these so we agree where we headed to. 1. Timeline I suggest stable release in two years time. Ready for distributions to switch from the current solution to the new solution. This derives a working component within a year. 2. Operating system support I believe that in two years we will end up with Linux, *BSD, and maybe Solaris, if it will magically gain some trust. OS X will be phased out in favor of Darwin. So OS X users can continue use current pcsc-lite no need to migrate them. Solaris will be supported only if there will be requirement after the new framework is stable. 3. CCID driver The CCID driver will be migrated to the new framework, dropping the libusb usage and use USB directly, this way it would be more efficient and can use as many feature as available in the operating system. Over the years, libusb was unmaintained, and even now it is difficult to see the 1.0 version stabilized. 4. My tasks Design and implement smartcard reader framework which will be single threaded, none blocking (client), process per reader, no runtime dependency. Based on OpenCT code base. Implement fake reader driver to allow sanity check of the implementation without the need of actual reader. Implement a prototype for the complex PC/SC functions, that demonstrate the feasibility of the new library. From our off list discussion it would be: SCardBeginTransaction SCardEndTransaction SCardGetStatusChange SCardCancel SCardTransmit 5. Your tasks If I complete (4) successfully (it would be for Linux at first), you continue and complete the PC/SC implementation as a client only library, and help me to perfect the solution at client side. 6. My tasks While you busy with (5), I will migrate the OpenCT's CCID driver into the new framework. The OpenCT CCID is much closer to this model, so it would be the easiest to to migrate and have the first working driver. I will also migrate eToken driver as it is simple and allow to demonstrate a simple driver. Implement the IFD Handler API reader driver as you requested. One thing I don't understand, if you state that only CCID compliant readers are available and all other drivers are unmaintained, why support this interface. Anyway, as we discussed unless you release me from this obligation I will implement a reader driver that use IFD Handler API in order to access legacy drivers. 7. Joint task Migrate the CCID driver into the new framework. 8. My task Open BSD migration. 9. Joint task (with help of more people) Stabilize the components. 10. Joint tasks Phase out pcsc-lite and OpenCT. > I propose to start a pcsclite/branches/2.0 or something similar on > Alioth pcsc-lite project. > > If needed I can ask to convert the pcsclite project to use TRAC on Alioth. In the spirit of cooperation, why not manage this project under the OpenSC-Project.org umbrella? It will send better message for users. Anyway, we will need at least the following repositories: 1. libscreader 2. pcsc-lite or pcsc-screader 3. screader-driver-ccid 4. screader-driver-etoken 5. screader-driver-etoken64 6. screader-driver-ifdh 7. screader-driver-rutoken <etc> Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
