Re: [opensc-devel] card minidriver update for windows.
On Mon, Jan 25, 2010 at 11:55 AM, Peter Stuge wrote: > > Certainly! This example is meant for Windows MinGW, but just add the > cross prefix for gcc and windres in Makefile and you're done. > > With my i686-mingw32 it builds to dlg.exe size 5632. libtool does it [almost] automatically. opensc uses libtool in order to compile version resources into executable. Any other resource may be added very simply. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
Andreas Jellinghaus wrote: > > Andreas Jellinghaus wrote: > > > > - 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. > > > > Dialogs in .rc plus a little C code works really well, is small and > > fast. http://stuge.se/dlg.zip is a minimal example. > > hmm. looks nice. can we create such binaries with the usual mingw > setup (cross-compile from linux)? Certainly! This example is meant for Windows MinGW, but just add the cross prefix for gcc and windres in Makefile and you're done. With my i686-mingw32 it builds to dlg.exe size 5632. > a simple gui with the cards we support listed, and a checkbox would > be all we need, I guess. and the app would set / remove the registry > keys to map those cards to the opensc mini driver. If the registry manipulation is straightforward then the program will be simple and tiny indeed. > maybe one or two entries with an input field instead of a name, > so people can enter ATRs we don't know yet, and map them to opensc > mini driver too. That's a good idea! //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
Am Montag 25 Januar 2010 10:20:55 schrieb Peter Stuge: > Andreas Jellinghaus wrote: > > > - 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. > > Dialogs in .rc plus a little C code works really well, is small and > fast. http://stuge.se/dlg.zip is a minimal example. hmm. looks nice. can we create such binaries with the usual mingw setup (cross-compile from linux)? a simple gui with the cards we support listed, and a checkbox would be all we need, I guess. and the app would set / remove the registry keys to map those cards to the opensc mini driver. maybe one or two entries with an input field instead of a name, so people can enter ATRs we don't know yet, and map them to opensc mini driver too. Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
On Jan 25, 2010, at 11:21 , Andreas Jellinghaus wrote: > Am Montag 25 Januar 2010 09:21:01 schrieb Martin Paljak: >> Hello, >> >> Some thoughts on the minidriver topic. >> >> In theory, it should look like this: >> >> minidriver -> libopensc -> pcsc > > hu? I thought the smart card base driver opens the > reader and looks at the ATR, and then loads the corresponding > mini card driver, thus we need a special hack to get the > already opened Reader from the smart card base driver. Yes, it does require special handling. But this is the "big picture". This has been noted by many, that to support the minidriver approach, hackery to pass in the existing handles must be used. It just requires special handling in libopensc. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
Am Montag 25 Januar 2010 09:21:01 schrieb Martin Paljak: > Hello, > > Some thoughts on the minidriver topic. > > In theory, it should look like this: > > minidriver -> libopensc -> pcsc hu? I thought the smart card base driver opens the reader and looks at the ATR, and then loads the corresponding mini card driver, thus we need a special hack to get the already opened Reader from the smart card base driver. > Thus it could sit in a separate driectory like src/minidriver/*. At least > it should omit "opensc" from the name and reside somewhere else than > libopensc - if it gets integrated into OpenSC it *will* be the OpenSC > mindriver interface. hmm, yes. "minidriver" would do fine. After all it is in the opensc source, so we know it is opensc related. But the name for the final binary should have "opensc" in it. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
Andreas Jellinghaus wrote: > > - 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. Dialogs in .rc plus a little C code works really well, is small and fast. http://stuge.se/dlg.zip is a minimal example. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
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 opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
Hello, Some thoughts on the minidriver topic. In theory, it should look like this: minidriver -> libopensc -> pcsc like there is on macosx: Tokend -> libopensc -> pcsc or the PKCS#11 module: opensc-pkcs11 -> libopensc -> pcsc Thus it could sit in a separate driectory like src/minidriver/*. At least it should omit "opensc" from the name and reside somewhere else than libopensc - if it gets integrated into OpenSC it *will* be the OpenSC mindriver interface. I have some pictures about the eID architecture/components of Estonian eID, I can modify them to make them look like the minidriver uses OpenSC as well. http://www.slideshare.net/martinpaljak/idkaardist-100/19 For PC/SC, I don't think it should be changed into a separate driver, the same codebase can be used to build a version suitable for minidriver. If the same exact libopensc dll can not be used, then at least the codebase can be re-used to build the minidriver dll Martin On Jan 22, 2010, at 17:17 , François Leblanc wrote: > > Just a correction of my first patch send concerning opensc minidriver for > windows, > > Now work with XP, vista and windows 7 at least with test application. > (for XP don't knows if certificates are loaded on windows container..., for > vista and 7 certutil command show me certificates on card.) > > Work to do: > > - Cleaning code. > - Look at pin management and certificate/private key link to improve. > - Improve register key management and .inf file to manage all cards (with > options to not manage some cards) > - Documentation > - Review licence of files > > Not tested: > > - Several kinds of card insertion (a westcos and a Cyberflex for example) > - Pinpad reader > - and lot of other future > > After this think we can have a first release that maybe submit for adding to > opensc. Like you can see, the module add only one source code file opensccm.c > and some code specific on reader-pcsc.c all this only for windows build it's > not too much. > > > In future if this working well, add code to update/write card with windows > cryptographics API, since this first release consider cards read only. > > > > Regards, > François. > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card minidriver update for windows.
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? * 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. * Makefile.am: it would be better to the new source files always, and simply have a big #ifdef around the whole code. that way tar.gz files will include the new code files without extra logic needed in the makefiles. * 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. * 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? > - 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... 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. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
