Re: [opensc-devel] Patch adding support for Aventra MyEID card
Martin Paljak wrote: > Just like the idea of OpenSC is to support via a single project / > API / library a bunch of cards instead every card making its own > "mycard-pkcs11.so", the same should be followed in command line > utilities. > > What do you think? I think that's a great idea. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for Aventra MyEID card
Aventra development wrote: > Currently the driver doesn't support PKCS initialization, we will > add this later. Until that becomes available it would be very good to have a standalone tool to do initialization. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SCA for Snow Leopard built yet?
Hello Martin, thanks for helping! On Sep 14, 2009, at 3:48 PM, Martin Paljak wrote: > After installing the OpenSC.pkg I have problems with missing libltdl. > 3.dylib: > I remember that it got bundled because it did not exist on machines > without Developer tools installed, but can't remember if it changed > with 10.5 or Need to investigate clean 10.4 and 10.5 installations > if the dylib is installed or not. Sorry, I forgot to bundle it. I confirm that both 10.5 and 10.6 do not have libltdl.3.dylib by default. > After fixing it Tokend works and certificates appear, great succes! > That's great! But can you actually use the token? In my case the certificates show up in the Keychain, but when I try to login with the card, it fails. If I try to login to a website with Safari using one of the certificates on the card, it also fails... Can you, for example, login to website with the card? > lrwxr-xr-x 1 root wheel 24 26. juuli 17:27 /usr/lib/libltdl. > 3.1.0.dylib -> /usr/lib/libltdl.3.dylib > lrwxr-xr-x 1 root staff 15 28. aug 11:17 /usr/lib/libltdl. > 3.1.4.dylib -> libltdl.3.dylib > lrwxr-xr-x 1 root wheel 15 28. aug 11:17 /usr/lib/libltdl. > 7.1.2.dylib -> libltdl.7.dylib > -rwxr-xr-x 1 root wheel 123888 18. mai 20:26 /usr/lib/libltdl. > 7.dylib > -rw-r--r-- 1 root wheel 318748 18. mai 20:26 /usr/lib/libltdl.a > lrwxr-xr-x 1 root wheel 24 14. sept 14:26 /usr/lib/ > libltdl.dylib -> /usr/lib/libltdl.3.dylib > > > Interestingly my personal OpenSC tree does not work and crashes, > even though it has 64bits. Probably there is difference in OSX > deployment target (I'm using 10.5, OpenSC.tokend has 10.4) > > Have you upgraded your eID patch? Would be OK to include it maybe? > The patch its almost done. We haven't released it yet because we need to test the "Change PIN" operation in the older version of the card, but we are waiting that one of those cards becomes available to us. Apart from that, its pretty much finished I guess - I hope to finish in the next few days (if I can get my hands on one the older cards...). Thank you. João > > > > > On 12.09.2009, at 19:10, João Poupino wrote: >> >> The Tokend was first compiled with Leopard's SDK, in order to support >> the i386 and ppc7400 architectures. >> >> To compile the Tokend for x86_64, using Snow Leopard's SDK, the >> following frameworks had to be changed from the Leopard versions >> (provided by Martin) to the Snow Leopard versions: >> >> Security.framework >> SecurityTokend.framework >> security_cdsa_client.framework >> security_cdsa_utilities.framework >> security_utilities.framework > > -- > Martin Paljak > http://martin.paljak.pri.ee > +372.515.6495 > > > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SCA for Snow Leopard built yet?
After installing the OpenSC.pkg I have problems with missing libltdl. 3.dylib: I remember that it got bundled because it did not exist on machines without Developer tools installed, but can't remember if it changed with 10.5 or Need to investigate clean 10.4 and 10.5 installations if the dylib is installed or not. After fixing it Tokend works and certificates appear, great succes! lrwxr-xr-x 1 root wheel 24 26. juuli 17:27 /usr/lib/libltdl. 3.1.0.dylib -> /usr/lib/libltdl.3.dylib lrwxr-xr-x 1 root staff 15 28. aug 11:17 /usr/lib/libltdl. 3.1.4.dylib -> libltdl.3.dylib lrwxr-xr-x 1 root wheel 15 28. aug 11:17 /usr/lib/libltdl. 7.1.2.dylib -> libltdl.7.dylib -rwxr-xr-x 1 root wheel 123888 18. mai 20:26 /usr/lib/libltdl.7.dylib -rw-r--r-- 1 root wheel 318748 18. mai 20:26 /usr/lib/libltdl.a lrwxr-xr-x 1 root wheel 24 14. sept 14:26 /usr/lib/libltdl.dylib - > /usr/lib/libltdl.3.dylib Interestingly my personal OpenSC tree does not work and crashes, even though it has 64bits. Probably there is difference in OSX deployment target (I'm using 10.5, OpenSC.tokend has 10.4) Have you upgraded your eID patch? Would be OK to include it maybe? On 12.09.2009, at 19:10, João Poupino wrote: > > The Tokend was first compiled with Leopard's SDK, in order to support > the i386 and ppc7400 architectures. > > To compile the Tokend for x86_64, using Snow Leopard's SDK, the > following frameworks had to be changed from the Leopard versions > (provided by Martin) to the Snow Leopard versions: > > Security.framework > SecurityTokend.framework > security_cdsa_client.framework > security_cdsa_utilities.framework > security_utilities.framework -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SC_FUNC_RETURN and ctx->debug >= level (/branches/martin/0.12)
Privet, On 14.09.2009, at 14:57, Aktiv Co. Aleksey Samsonov wrote: > Patch for /branches/martin/0.12 revision 3732 is in attachment: > rollback check (ctx->debug >= level) in SC_FUNC_RETURN macro. > Martin, could you please add it? Thanks for double-checking, applied/rolled back in r3733 This brings me to another issue I wanted to ask from fellow developers: some kind of order in the debug level usage, as currently it ranges from 0 to 4 in SC_* macros. sc_debug() does not take a level option to allow the developer to specify a "level of interest" to the debug message and so there are 200+ manual if checks for levels ranging from 0 to 6 in different code files. Controlling debug output and level is controlled by a number in the config file but as much as I've had to instruct somebody to enable logging I say "write 9 to opensc.conf and send me the output" as a "all or nothing" approach. So, either: - log level concept can be removed (0/1) altogether - or levels can be better defined and limited (3, not more than 4 levels with more well-defined purposes) and a SC_DEBUG macro with a level parameter created. code in log.c checks for debug level > 0 so redundant >= 1 style checks are scattered across files. Unlike long-running processes (servers) I have personally not found a reason to have "some debug" when I really need "as much debug as possible" from OpenSC, partly because I don't know which smaller than 9 number would give not too much garbage but enough information to be useful. In normal situations everything should just work and no debug log generated at all, but when things break it is always the best to have as much logs as possible. Thoughts? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SC_FUNC_RETURN and ctx->debug >= level (/branches/martin/0.12)
Hello!
Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback
check (ctx->debug >= level) in SC_FUNC_RETURN macro.
Martin, could you please add it?
Thanks
diff -u -r 0.12-r3732/src/libopensc/log.h 0.12-r3732_new/src/libopensc/log.h
--- 0.12-r3732/src/libopensc/log.h 2009-09-14 09:35:14.0 +0400
+++ 0.12-r3732_new/src/libopensc/log.h 2009-09-14 15:40:03.0 +0400
@@ -59,7 +59,9 @@
#define SC_FUNC_RETURN(ctx, level, r) do { \
int _ret = r; \
- sc_do_log(ctx, SC_LOG_TYPE_DEBUG, __FILE__, __LINE__, __FUNCTION__,
"returning with: %d\n", _ret); \
+ if (ctx->debug >= level) { \
+ sc_do_log(ctx, SC_LOG_TYPE_DEBUG, __FILE__, __LINE__,
__FUNCTION__, "returning with: %d\n", _ret); \
+ } \
return _ret; \
} while(0)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for Aventra MyEID card
On 14.09.2009, at 10:42, Andreas Jellinghaus wrote: > for many cards we have a special tool so we access low level functions > of the card like formatting, debuggging, getting firmware version etc. > are there any such functions that could require such a low level tool? > or does the card driver everything, so no need for that? Actually, if the functions overlap, instead of getting many-many small utilities with almost similar functionality, we might extend opensc- tool (or pkcs15-init?) to do most of the functions depending on the card type and if there is some really exotic stuff, opensc-tool -- special-mycard-erase would be a better option, IMHO, than mycard-tool with only option --erase-special. Of course it makes sense to split it on source code file level but a single interface for the user feels simpler at least to me. Just like the idea of OpenSC is to support via a single project / API / library a bunch of cards instead every card making its own "mycard-pkcs11.so", the same should be followed in command line utilities. What do you think? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for Aventra MyEID card
Hi! Thanks for the comments Andreas and Martin. I will look into these once you have committed the current patch. I could then fix the things Martin commented on. I will then post a new patch file and hope to also have a small wiki page with information about the card. We will send you Andreas some pre-initialized test cards. The card is a standards based PKI card using Java technology. It supports common ISO7816 and PKCS#15 standards. The cards are commonly used in Finnish health care and other organizations and companies. Currently the driver doesn't support PKCS initialization, we will add this later. Regards, Toni -Original Message- From: Andreas Jellinghaus [mailto:a...@dungeon.inka.de] Sent: 14. syyskuuta 2009 10:43 To: opensc-devel@lists.opensc-project.org Cc: Aventra development Subject: Re: [opensc-devel] Patch adding support for Aventra MyEID card hi Toni, the patch looks good, here are the small issues I found: * doesn't apply to trunk, but only very small fixes needed (westcos driver was added last week, so off by one errors) * indent creates some ugly long lines in its default formatting, in some places a lot of tabs could be removed (usualy the function definition, 2nd+ line) to keep the code more readable. * no need to patch Makefile.in * a few dos \r\n line ends in the patch all these things are minor, I could edit the source and commit the current patch with minimal changes. lets see if anyone finds other issues. (also I didn't compile-test the patch so far) can you tell us more about the card? I read on your web page you use javacards with your own applet? will this opensc implementation allow everything we can do with normal cards, or is it in anyway limited? is the card if used with opensc compatible with the software you sell or are there any issues? and if you want to donate a card or two for testing, my address is Andreas Jellinghaus, Vogelhartstrasse 17, 80807 Munich, Germany :) for many cards we have a special tool so we access low level functions of the card like formatting, debuggging, getting firmware version etc. are there any such functions that could require such a low level tool? or does the card driver everything, so no need for that? Once the driver is commited we would welcome a wiki page about the card, so users can read up what it is, where to buy it, if there are limitations (e.g. is your software required to initialize the card or anything like that?) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] westcos broke compiling without openssl
Andreas Jellinghaus: > I haven't checked myself, but someone told me > that opensc trunk isn't compiling without openssl. > > can anyone check? Version: 0.11.9-svn (trunk-r3720) User binaries: /usr/local/bin Configuration files: /usr/local/etc XSL stylesheets: /usr/share/sgml/docbook/xsl-stylesheets-1.49-1 man support: yes doc support: no zlib support:yes readline support:yes iconv support: yes OpenSSL support: no PC/SC support: no OpenCT support: no NSPlugin support:no PC/SC default provider: pinentry:/usr/bin/gpinentry Host:i686-pc-linux-gnu Compiler:gcc Preprocessor flags: Compiler flags: -fno-strict-aliasing -g -O2 Linker flags: Libraries: LTLIB_CFLAGS: LTLIB_LIBS: -lltdl READLINE_CFLAGS: READLINE_LIBS: -lreadline -lncurses ZLIB_CFLAGS: ZLIB_LIBS: -lz ICONV_CFLAGS: ICONV_LIBS: OPENSSL_CFLAGS: OPENSSL_LIBS:-lssl -lcrypto -ldl OPENCT_CFLAGS: OPENCT_LIBS: PCSC_CFLAGS: LIBASSUAN_CFLAGS: LIBASSUAN_LIBS: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/common -DOPENSC_CONF_PATH=\"/usr/local/etc/opensc.conf\" -fno-strict-aliasing -g -O2 -MT card-westcos.lo -MD -MP -MF .deps/card-westcos.Tpo -c card-westcos.c -fPIC -DPIC -o .libs/card-westcos.o card-westcos.c: In function 'westcos_get_crypte_challenge': card-westcos.c:772: error: 'DES_key_schedule' undeclared (first use in this function) card-westcos.c:772: error: (Each undeclared identifier is reported only once card-westcos.c:772: error: for each function it appears in.) card-westcos.c:772: error: expected ';' before 'ks1' card-westcos.c:780: error: 'const_DES_cblock' undeclared (first use in this function) card-westcos.c:780: error: expected expression before ')' token card-westcos.c:781: error: expected expression before ')' token card-westcos.c:782: error: expected expression before ')' token card-westcos.c: In function 'westcos_sign_decipher': card-westcos.c:1190: error: 'mem' undeclared (first use in this function) make[3]: *** [card-westcos.lo] Error 1 make[3]: Leaving directory `opensc-trunk-r3720/src/libopensc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `opensc-trunk-r3720/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `opensc-trunk-r3720' make: *** [all] Error 2 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for Aventra MyEID card
Moi, On 14.09.2009, at 9:54, Aventra development wrote: > Also if there are some other things that we should do, please inform > us what exactly we should, > since this is the first time we contribute to the OpenSC project. A few minor ones: - // comments -> /* comments */, no commented code - sc_error() -> sc_debug() - instead of 0 return SC_SUCCESS where applicable Also please prepare a wiki page with information about the card, where to buy it, where it is used, can the applet be used with any Java card etc. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] westcos broke compiling without openssl
I haven't checked myself, but someone told me that opensc trunk isn't compiling without openssl. can anyone check? thanks, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for Aventra MyEID card
hi Toni, the patch looks good, here are the small issues I found: * doesn't apply to trunk, but only very small fixes needed (westcos driver was added last week, so off by one errors) * indent creates some ugly long lines in its default formatting, in some places a lot of tabs could be removed (usualy the function definition, 2nd+ line) to keep the code more readable. * no need to patch Makefile.in * a few dos \r\n line ends in the patch all these things are minor, I could edit the source and commit the current patch with minimal changes. lets see if anyone finds other issues. (also I didn't compile-test the patch so far) can you tell us more about the card? I read on your web page you use javacards with your own applet? will this opensc implementation allow everything we can do with normal cards, or is it in anyway limited? is the card if used with opensc compatible with the software you sell or are there any issues? and if you want to donate a card or two for testing, my address is Andreas Jellinghaus, Vogelhartstrasse 17, 80807 Munich, Germany :) for many cards we have a special tool so we access low level functions of the card like formatting, debuggging, getting firmware version etc. are there any such functions that could require such a low level tool? or does the card driver everything, so no need for that? Once the driver is commited we would welcome a wiki page about the card, so users can read up what it is, where to buy it, if there are limitations (e.g. is your software required to initialize the card or anything like that?) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
