Re: [opensc-devel] [opensc-commits] svn opensc changed[4768] ias/ecc: simultaneous run of opensc tool that address different readers
Martin Paljak wrote: Hello, On Sep 25, 2010, at 11:19 PM, webmas...@opensc-project.org wrote: Revision: 4768 Author: viktor.tarasov Date: 2010-09-25 20:19:08 + (Sat, 25 Sep 2010) Log Message: --- ias/ecc: simultaneous run of opensc tool that address different readers opensc-explorer and pkcs15-crypt Can you explain what is the requirement for this? Why does xxx-tool --reader Your Reader Name not work? Other than that, the need to pass in a specific reader and bypass the reader list detection needs a generalized approach. OpenSC.tokend could make use of it, instead of filtering the readers itself and minidriver would need special handling and fetch the card and context handles. But the overall impact would still be the same: force pcsc_detect_readers do only discover a single reader, based on context creation parameters. In fact, that was the initial intention -- 'force pcsc reader to only discover a single reader'. Actually in 'reader-pcsc', when getting the reader's list, the SCardConnect(SCARD_SHARE_DIRECT) is called for every reader. So, when one process holds the first reader, the second process cannot access the second reader -- it stopped on the first reader's mutex. I was looking to test the possible problems of multi OpenSC process, but finally it's revealed to be useless -- beyond the pcsc reader, 'multi OpenSC process' is not concerned by the 'multi OpenSC threads' problems. -- Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4771] ias/ecc: change path for Windows registers
Peter Stuge wrote: Martin Paljak wrote: On Sep 25, 2010, at 11:19 PM, webmas...@opensc-project.org wrote: ias/ecc: change path for Windows registers ... - rc = RegOpenKeyEx(HKEY_CURRENT_USER, Software\\OpenSC, 0, KEY_QUERY_VALUE, hKey); + rc = RegOpenKeyEx(HKEY_CURRENT_USER, Software\\OpenSC Project\\OpenSC, 0, KEY_QUERY_VALUE, hKey); Why does Software\\OpenSC not work for you? I think it's supposed to be one key for the vendor, and then another key underneath it for the product. In fact -- vendor's and product's key. That's the way that the other card producers install their middleware (Gemalto, Oberthur), that's also the case of the first example in the WIX tutorial, and also, maybe one day, there will be more the one OpenSC windows applications. For me Software\OpenSC\OpenSC would also be OK. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card-max_recv_size problem
Hello, On Sun, Sep 26, 2010 at 08:47, Andre Zepezauer andre.zepeza...@student.uni-halle.de wrote: With the current trunk 2048b keys on CardOS are working again. Therefore the max_*_size patches work for me. But I have two suggestions: [1] The intended overriding will not work, if the card has a default value of zero for max_*_size. If this is the case, then limitations imposed by the reader are not honoured. It would be a programming error, which does not make sense. Śetting this to 0 would mean I'm a card and I can't receive or send data, but here is my 1K LOC driver nevertheless. [2] Why not moving this to the corresponding card driver? I'm not sure but card-gpk.c should be the right place. Yes, seems so. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4768] ias/ecc: simultaneous run of opensc tool that address different readers
On Sun, Sep 26, 2010 at 09:17, Viktor TARASOV viktor.tara...@opentrust.com wrote: Other than that, the need to pass in a specific reader and bypass the reader list detection needs a generalized approach. OpenSC.tokend could make use of it, instead of filtering the readers itself and minidriver would need special handling and fetch the card and context handles. But the overall impact would still be the same: force pcsc_detect_readers do only discover a single reader, based on context creation parameters. In fact, that was the initial intention -- 'force pcsc reader to only discover a single reader'. Actually in 'reader-pcsc', when getting the reader's list, the SCardConnect(SCARD_SHARE_DIRECT) is called for every reader. So, when one process holds the first reader, the second process cannot access the second reader -- it stopped on the first reader's mutex. Is this on Windows? I remember testing for exclusive access but maybe only with pcsc-lite. If it does not work if the reader is in exclusive mode it is a bug in pcsc-driver that should not be fixed via tools. opensc-tool --reader should work as expected with whatever states the readers are in. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card-max_recv_size problem
On Sun, 2010-09-26 at 09:22 +0300, Martin Paljak wrote: Hello, On Sun, Sep 26, 2010 at 08:47, Andre Zepezauer andre.zepeza...@student.uni-halle.de wrote: With the current trunk 2048b keys on CardOS are working again. Therefore the max_*_size patches work for me. But I have two suggestions: [1] The intended overriding will not work, if the card has a default value of zero for max_*_size. If this is the case, then limitations imposed by the reader are not honoured. It would be a programming error, which does not make sense. Śetting this to 0 would mean I'm a card and I can't receive or send data, but here is my 1K LOC driver nevertheless. The value of max_*_size actually defaults to zero [3] and will stay so, if not overridden by the card driver. See how it is used in the iso-driver. IMHO zero is a legal value and means that no restrictions are imposed by the card. Same is true for reader drivers. [2] Why not moving this to the corresponding card driver? I'm not sure but card-gpk.c should be the right place. Yes, seems so. [3] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card.c#L58 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Upper limit for file size to upload into 'contrib'
Hi, what is the maximal possible size of the file to commit into the 'svn/files/trunk/contrib/' ? My attempt to upload the MSI of the opensc-sm, that weights a little bit more the 2M, was refused with error '413 Request Entity Too Large'. Kind wishes, Viktor. Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upper limit for file size to upload into 'contrib'
Am Sonntag 26 September 2010, um 14:52:58 schrieb Viktor TARASOV: Hi, what is the maximal possible size of the file to commit into the 'svn/files/trunk/contrib/' ? My attempt to upload the MSI of the opensc-sm, that weights a little bit more the 2M, was refused with error '413 Request Entity Too Large'. many files in the files svn are 10mb or larger. so 2mb shouldn't be an issue. also there is pletty of disk space left and we have no hook scripts to enforce any limites. so maybe this is a client issue? do you use a web proxy? http or https connection? Regards,Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upper limit for file size to upload into 'contrib'
Some time ago I made a fileserver (fileser...@opensc-project.org) SSH account where every developer can plug in with a SSH key and upload files [1] which are not really related to releases or anything. Your public key is not on the list. [1] http://www.opensc-project.org/downloads/ On Sun, Sep 26, 2010 at 17:24, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Sonntag 26 September 2010, um 14:52:58 schrieb Viktor TARASOV: Hi, what is the maximal possible size of the file to commit into the 'svn/files/trunk/contrib/' ? My attempt to upload the MSI of the opensc-sm, that weights a little bit more the 2M, was refused with error '413 Request Entity Too Large'. many files in the files svn are 10mb or larger. so 2mb shouldn't be an issue. also there is pletty of disk space left and we have no hook scripts to enforce any limites. so maybe this is a client issue? do you use a web proxy? http or https connection? Regards,Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Visual Studio Integration
Hello, Patch : Is not patch it's folder group with configuration file for use Visual studio (.vsproject, .sln). Dependencies : For dependencies I use OpenSSL.exe, iconv.exe, zlib.dll, libtdll.dll extracted from the executable made by François Leblanc. For the moment this version is for XP but with Visual Studio 2010 it's possible to generate for 64bits mode. You can generate with the command line but it's not the goal because it's for use Graphical Debug mode but it's possible to generate with command line. Visual Studio 2005 : I can make version for Visual Studio 2005 because my school offers me the opportunity to have access to all Microsoft software. But I need time for make this version. Number of Project : I can't reduce number of project. and I can't use subproject. Don't existe in Visual Studio. Where I can deposit my zip file for you to view? Regards, Guillaume JEAN -Message d'origine- De : martin.pal...@gmail.com [mailto:martin.pal...@gmail.com] De la part de Martin Paljak Envoyé : vendredi 24 septembre 2010 21:28 À : JEAN Guillaume Cc : opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] Visual Studio Integration Hello, On Fri, Sep 24, 2010 at 15:59, JEAN Guillaume guillaume.j...@supinfo.com wrote: Hello, I just finished the first version of OpenSC integration in Visual Studio. This integration allows you to use debug breakpoints and view values of variables, so you can enjoy all the Visual Studio features. This it gives opportunity to more developers to help improve OpenSC and therefore improve development and distribution. Cool! Where is the patch? How do you handle building dependencies (OpenSSL, iconv, zlib, libltdl) ? Does it support building for 64 bits? Can the build be automated from command line, without requiring modifications via GUI? For my part I intend to maintain this solution so that it remains functional, of course within the limits of available time that my school gives me. I also intend to add all improvements that will be considered useful. E.g. port the architecture to Visual Studio 2005 and 2008 for a larger opening. Or even integrate other OpenSC projects. I only have VS2005, which version are you targeting? I think the basic vs2005 project could also be used (or at least imported) with newer versions verbatim, as OpenSC does not use .NET or any of the windows frameworks that might require a newer version of VS. I don't think all developers (who are not fulltime Windows developers by profession or buy the latest MS developer tools as they are released) upgrade the OS that often. I know I don't :) I unfortunately have to abandon the use Makefiles because Visual Studio doesn't like to use them too much, and it prevents me to use debug mode for each generated dll or .exe. So I find myself with a project for each lib, dll, or executable generated. But it is mandatory with Visual Studio to have a project for each generated executable or dll. There are only a few DLL-s and as many .exe-s as there are tools. That's an OK number of targets (subprojects?). Providing alternatives to the Windows nmake files is good. I would like to discuss with you whether it would be possible to have a place to continue this adventure with your community. Good native windows building would be useful to OpenSC. What kind of place do you have in mind? Cheers, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to MyEID profile
Hi, -Original Message- From: Viktor TARASOV Hi, Aventra development wrote: Here is a small patch that modifies the MyEID profile. This profile now initializes the cards like we want them (users are of course free to modify the profile to get cards like they want, but we think this should be the default). I suppose the ACL for card initialization (clearing card) is not desired to be NONE and therefore we undefined the KEEP_AC_NONE_FOR_INIT_APPLET, and you can anyway set it to anything you like by configuring the profile. Your patch do not working for me when applied to trunk . The reasons are: - actual implementation of pkcs15init needs to verify 'DELETE' acl of the PKCS15-AppDF when doing 'create object' operations. So, your have to set it to 'NONE' or 'User PIN'; - take into account my mail http://www.opensc-project.org/pipermail/opensc-devel/2010- September/014865.html illustrated by diff from http://www.opensc-project.org/pipermail/opensc-devel/2010- September/014867.html In attachment there is a diff for myeid.profile (relative to trunk) that actually 'works for me'. Thanks Viktor, the your profile patch looks good. I did not test the patch I posted against current trunk, instead I used snapshot from changeset 4707, sorry about that. There is a downside with this configuration, pkcs15-init now asks many times (5 times I think) for the USER PIN when it initializes the MyEID card and creates the required files (it does not matter what you enter, because it wont be verified since the card is in creation state). I propose you to use '--pin' argument for the 'pkcs15-init' command. Pkcs15-init creates the SO-PIN, but not the USER PIN. It would be nice if pkcs15-init would create both PINs, since it is built to support two PINs (User and SO). Currently we create the user pin after initialization and finalize the card after that. If somebody knows how to get rid of the unnecessary user PIN queries please apply fix or help us do it. Pkcs15-init creates both PINs with this kind of command: #pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 -- so-puk 123456 --pin --puk -F Great, this makes the initialization much nicer. #pkcs15-tool --list-pins Using reader with a card: OmniKey CardMan 3121 00 00 PIN [Security Officer PIN] Object Flags : [0x3], private, modifiable ID : ff Flags : [0xB0], initialized, needs-padding, soPin Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 3 Type : ascii-numeric Path : PIN [IDX-SCM] Object Flags : [0x3], private, modifiable ID : 53434d Flags : [0x30], initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 1 Type : ascii-numeric Path : Please apply this small patch, thanks! Kind regards, Toni Kind wishes, viktor. Best wishes, Toni ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Visual Studio Integration
Hello, On Sep 26, 2010, at 7:13 PM, JEAN Guillaume wrote: Hello, Patch : Is not patch it's folder group with configuration file for use Visual studio (.vsproject, .sln). ... Where I can deposit my zip file for you to view? You should start by upgrading the longstanding ticket [1] and attach your zip file for review. [1] http://www.opensc-project.org/opensc/ticket/105 -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Sun, Sep 26, 2010 at 11:51 PM, Martin Paljak mar...@paljak.pri.ee wrote: But this does not remove the api.out/api.tmp/api.work voodoo, what was one of my goals and what caused problems in my original change patch. I knew only the goal was to remove the wiki stuff... Can you explain why do you want to add? Which voodoo you referring? Also, would it not make sense to re-generate changelog whenever make dist is run inside a svn checkout? If people work with none formal checkouts, they should not be forced for internet connection. The detailed commit log is something you want when you release a new version. So the only one who will use the Generate-ChangeLog is you... :) This previous mechanism also worked on fresh checkout only, once the ChangeLog was created it was never refreshed. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Sep 27, 2010, at 1:42 AM, Alon Bar-Lev wrote: On Sun, Sep 26, 2010 at 11:51 PM, Martin Paljak mar...@paljak.pri.ee wrote: But this does not remove the api.out/api.tmp/api.work voodoo, what was one of my goals and what caused problems in my original change patch. I knew only the goal was to remove the wiki stuff... Can you explain why do you want to add? Which voodoo you referring? There was a link to a patch [1] in my original e-mail [2] which had a problem with make distcheck: (cd doc make top_distdir=../opensc-0.12.0-svn distdir=../opensc-0.12.0-svn/doc \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[2]: *** No rule to make target `man/*.1', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distcheck] Error 1 Compare current doc/Makefile.am with the shorter one for the voodoo. [1] http://pastebin.com/iZLrBywD [2] http://www.opensc-project.org/pipermail/opensc-devel/2010-September/015014.html -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Mon, Sep 27, 2010 at 7:15 AM, Martin Paljak mar...@paljak.pri.ee wrote: On Sep 27, 2010, at 1:42 AM, Alon Bar-Lev wrote: On Sun, Sep 26, 2010 at 11:51 PM, Martin Paljak mar...@paljak.pri.ee wrote: But this does not remove the api.out/api.tmp/api.work voodoo, what was one of my goals and what caused problems in my original change patch. I knew only the goal was to remove the wiki stuff... Can you explain why do you want to add? Which voodoo you referring? There was a link to a patch [1] in my original e-mail [2] which had a problem with make distcheck: (cd doc make top_distdir=../opensc-0.12.0-svn distdir=../opensc-0.12.0-svn/doc \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[2]: *** No rule to make target `man/*.1', needed by `distdir'. Stop. make[1]: *** [distdir] Error 1 make: *** [distcheck] Error 1 Compare current doc/Makefile.am with the shorter one for the voodoo. [1] http://pastebin.com/iZLrBywD [2] http://www.opensc-project.org/pipermail/opensc-devel/2010-September/015014.html But it is working correctly, that patch was incorrect. Please explain in some more details what is the problem with current trunk, so I can fix it. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Sep 27, 2010, at 8:32 AM, Alon Bar-Lev wrote: On Mon, Sep 27, 2010 at 7:15 AM, Martin Paljak mar...@paljak.pri.ee wrote: Compare current doc/Makefile.am with the shorter one for the voodoo. [1] http://pastebin.com/iZLrBywD [2] http://www.opensc-project.org/pipermail/opensc-devel/2010-September/015014.html But it is working correctly, that patch was incorrect. Leaving the possible changed logic for ChangeLog generation aside, what was incorrect in that patch? Please explain in some more details what is the problem with current trunk, so I can fix it. I'd like to clean up doc directory, the api directory and the symlinking in doc/Makefile.am are not needed for manpage generation. That was one of the changes in my original patch that actually triggered the distcheck problem, removing wiki dumping was not a problem. If you could also fix my original root cause would be great. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
