Hello, On Jan 25, 2010, at 10:10 , Andreas Jellinghaus wrote: > A few things I noticed: > * latest changes martin made to slot/reader logic etc. will break > your code. martin, can you help to port it to latest trunk? 1. sc_disconnect_card() does not have the unused action parameter. 2. there are no slots in libopensc. Slots only exist in PKCS#11. 3. sc_ctx_get_reader_by_name(char * name) and sc_ctx_get_reader_by_id(int id). Id is the location in the list which mimics the old behavior. I saw in the code a place that can use sc_ctx_get_reader_by_name(char * name)
> * the reader driver for the card module: maybe it would be clearer > if it had a file of its own? or does it share code with the pcsc > reader driver? not sure what is best. Basically it is a specialized case for reader-pcsc.c, much like the differences in pcsc-lite and windows implementation require minor #ifdefs. I'm not sure but IIRC minidriver had specific requirements on dll-s (and/or the location of those dll-s) it would be able to use so it might be anyway needed to build a static/separate version of libopensc(+minidriver) for the minidriver. > * the card module: if we re-arrange the libraries (details still under > discussion), it might be better to put that code into some other > directory, or maybe a new one? maybe the code will want to use > pkcs15init functions one day, so libopensc/ wouldn't be a good > place then. pkcs15init should be hidden inside libopensc. > * linking: it might be easier for all users, if we create a fat binary > at least with all opensc parts included (i.e. not linking libopensc > as shared library), and maybe also statically link other shared libs > used (I guess only libcrypto and libltdl)). > at least I think library hell has been an issue, so if there is a > single binary that needs to be placed in system32 (or some other place), > that is much easier, than if it depends on more dlls. > (also unix library revisions don't map well to windows, so several > apps with their own copy of openssl don't play well I guess...) > >> - Look at pin management and certificate/private key link to improve. > > I saw some references to pin caching IIRC. not sure if that was the new > stuff we now use or the old stuff martin throw out (we had two or three > parts of the code doing more or less the same thing), so there could be > issues / merge problems. martin, can you have a look? If BaseCSP does some PIN caching itself, it should not be done by libopensc. If basecsp does not do it, but the minidriver has to do it (for some reason) it should be done in libopensc level and not in minidriver. >> - Improve register key management and .inf file to manage all cards (with >> options to not manage some cards) - Documentation > > hmm. a simple gui app could help users to manage that. but no idea what > an easy way to write a simple gui is on windows these days. or maybe > a nice installer package instead? we had a nsis installer once... Windows does provide a GUI to access operations like PIN changes etc. If I remember correctly one had to specify ATR-s on what the minidriver will engage. This could go in an installer as installation options with "check the cards you want to manage with minidriver" together with a catch-all option as well. > documentation: could be placed in the wiki, maybe with the first > line telling users: this functionality will be available with opensc 0.12.* > so current users are not confused. Most probably this functionality will be available once a windows installer with 0.12 is available :) -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
