Re: [opensc-devel] pam_pkcs11 with many certificates on a single token
frederic.comb...@cea.fr wrote: > Here is my patch (actually, 2 patches that depend if the patch > concerns only the error 2328 (patch 1) or the whole block > processing the return value of verify_certificate() (patch 2)). Patch 1 is obviously incorrect because your change is inside a conditional. Patch 2 is the correct change in code flow, but please do not ever use comments to "remove" source code. The version control system keeps track of history, and commented out code is very confusing, not to mention ugly. It would be great if you sent the change in an easy format. Ludovic mentioned pull requests. You'll need to know git and github specifics to do that. If you don't, maybe someone can generate a commit in your name. Thanks //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] STARCOS 3.0 cards with SafeSign Identity Client
Hi David. Sorry for the late reply; I was just searching my email for SafeSign and found yours. Coincidentally, I was testing a Crescendo C700 (3B:DF:18:FF:81:31:FE:45:80:59:01:80:48:49:44:43:37:30:30:73:00:01:1B:33) that was also initialized with SafeSign Identity Client. I couldn't figure out how to get it to work with pkcs15-tool, but I implemented my own reader in Java. Here's what I found when poking around and comparing it to the MyEID card: - It doesn't support select by relative or absolute path, only select by name (PKCS15 AID) and then select by file id. - The PIN is 4 to 15-byte 00-padded. - There's no private key file, so you don't need to select it or give the file id to to MSE Set command. - MSE Set data was picky (84 01 00 80 01 02); reversing the fields 84 and 80 caused it to fail. I'm not sure how to modify pkcs15-tool to make it work, but I know it should be possible. Yonathan ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Ludovic Rousseau wrote: > Merging a pull request from github adds a "merge pull request" commit. > The history is then not very nice (linear) but I don't know a better > way using the github web interface. It isn't neccessary to use the github web interface just because github is used to host the repository. It works just as well to pull from any remotes and create fast-forward merges. But of course that will then work around the pull request workflow that github enforces. Greg Troxel wrote: > >> You should rebase your patches above OpenSC/OpenSC master. > > > > Ok, but pardon my git ignorance: I thought that one should never > > rebase a tree that will be published and pulled from? Or only if it's > > published and someone tries to *base a new tree* off of it? > > This is somewhat controversial, but from my experience in both open > source and large private projects, the key issue is not to rebase > branches that other people have made commits on top of, or merged into > other branches. I disagree that rebasing is controversial. This is just a tool. Rewriting history is never a problem, as long as everyone who is working together wants to understand how repositories work and how easy it is to resync with rewritten branches. Given a local branch foobar that tracks contributor/master here's what to do when the contributor has rewritten her master: git checkout -b orig_contrib_master contributor/master && \ git fetch contributor && \ git rebase --onto contributor/master orig_contrib_master foobar Clean up after the rebase is done: git branch -D orig_contrib_master Since rebase of the local branch is required, of course it is important that the mechanics of rebase are well understood. > I find that it's helpful to rebase branches proposed for merging. There are arguments both ways. I like the look of linear history. On the other hand, depending on the development model, merges may be a more accurate representation of the code history. Viktor Tarasov wrote: > I also vote for rebase of the feature branch before merging it to > the master branch. Note that any testing and review of the branch should happen *after* that rebase, to avoid a lot of wasted effort. > If this procedure seems annoying, then use cherry-pick, especially > when it's going about the minor changes. cherry-pick is almost the only thing that rebase does. It's often easier to just use interactive rebase to do the picking. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Le 10/12/2012 17:10, Greg Troxel a écrit : > Anthony Foiani writes: > >> Ludovic, greetings -- >> >> On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau >> wrote: >>> 2012/12/8 Anthony Foiani : Greetings -- I have two small patches which you might want to consider integrating. (And given that I can't get git to do what I want, you probably want to just cherry-pick these, as I suspect I've completely destroyed my repo history...) >>> You should rebase your patches above OpenSC/OpenSC master. >> Ok, but pardon my git ignorance: I thought that one should never >> rebase a tree that will be published and pulled from? Or only if it's >> published and someone tries to *base a new tree* off of it? > This is somewhat controversial, but from my experience in both open > source and large private projects, the key issue is not to rebase > branches that other people have made commits on top of, or merged into > other branches. I find that it's helpful to rebase branches proposed > for merging. The point for me is not so much to have them based off > recent master to avoid a merge commit, but to produce the clean series > of commits that would have appeared had there been no mistakes. > > Achieving the goal of not rebasing branches others have derived commits > From can be accomplished by > > not rebasing published branches > > or > > having an understanding within the project that branches should not be > cross-merged, so that rebasing them is still safe. Even if multitple > people commit to a branch, with a little coordination this is not a > big deal. I also vote for rebase of the feature branch before merging it to the master branch. If this procedure seems annoying, then use cherry-pick, especially when it's going about the minor changes. If no objections, I will rebase two last commits of the current 'master'. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
Hello, Le 10/12/2012 17:46, Lukas Wunner a écrit : > I've issued pull request #111 which enhances pkcs15-gemsafeV1.c > by two features: Build of the merged repository for pull request #111 fails on Windows (Vista). You can reach the compilation logs of the failed jenkins job using the link in description of your pull request. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Muscle smart card Applet various versions from M.U.S.C.L.E. and OpenSC
I am not using the Muscle card applet, but was looking looking at the OpenSC debug log for this thread: Re: [opensc-devel] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!! The OpenSC card-muscle.c (0.12.2 or 0.13.0) is looking for PROTO_VERSION_MAJOR=1 The author of the original note said: > I've loaded and initialized Muscle applet (0.9.11) on it. This appears in the log that GET_STATUS is returning: 00 01 00 05 ... i.e. PROTO_VERSION_MAJOR=0, PROTO_VERSION_MINOR=1 This version from 2003-12-19, does not sound like the latest to me... Yet in the Muscle CVS archives: http://anonscm.debian.org/viewvc/muscleplugins/trunk/MCardApplet/ as of 4 years ago has version.properties has: APPLET_VERSION_MAJOR=0 APPLET_VERSION_MINOR=9 PROTO_VERSION_MAJOR=1 PROTO_VERSION_MINOR=3 And there have been changes in the SVN 9 months ago, 2 years ago and 3 years ago, which are not reflected in the Download page: https://alioth.debian.org/frs/?group_id=30111 Can the download versions be update, or the page change to say compile it yourself? Or point to the OpenSC page? Then on OpenSC-project: http://www.opensc-project.org/opensc/wiki/MuscleApplet it says: "OpenSC supports the Muscle applet, available from Debian SVN:" svn co svn://svn.debian.org/muscleplugins/trunk/MCardApplet (This appears to be the same SVN as on the Muscle page, revision 298 from 9 months ago.) "An updated version, targeting recent JavaCard 2.2.2 cards with extended APDUs is available from github:" http://github.com/martinpaljak/MuscleApplet This github is 3 years old, yet changes where made to the Muscle SVN 9 months ago. https://github.com/martinpaljak/MuscleApplet/blob/master/src/com/musclecard/CardEdge/CardEdge.java (3 years old) buffer[pos++] = (byte) 1; // Major Card Edge Protocol version n. buffer[pos++] = (byte) 3; // Minor Card Edge Protocol version n. buffer[pos++] = (byte) 0; // Major Applet version n. buffer[pos++] = (byte) 9; // Minor Applet version n. Which is in line with the PROTO_VERSION_MAJOR the OpenSC code is looking for. Can Martin and Ludovic get together and get these versions in sync, and make it so others don't download the 9 year old version? Thanks. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!!
More on this. Looking at the trace you did send on 12/9/2012: line 418: 0x7fff706e5cc0 14:39:03.351 [pkcs15-tool] card.c:180:sc_connect_card: trying driver: muscle causes the muscle_match_card in card-muscle.c to try and select the muscle applet with APDU: 00 A4 04 00 05 A0 00 00 00 01 with response: 90 00 It then reads some version information for the applet on the card APDU: B0 3C 00 00 40 with response: 00 01 00 05 00 00 75 30 00 00 5E F6 02 02 00 00 90 00 It is Successful, but response[0] == 0x00, but muscle_match_card is looking for 0x01 so it does not recognize the applet. Can you check how you loaded the applet. On 12/10/2012 9:54 AM, Douglas E. Engert wrote: > > > On 12/9/2012 9:56 AM, Ludovic Rousseau wrote: >> 2012/12/9 Rns Course : >>> Another request of you: >>> what's your opinion about windows version of opensc (0.12.2 or 0.13.0) and >>> the problem "File not found" in pkcs15 initialization? > > Why use 0.13.0: > o 0.13.0 has many more fixes. > o You will get better responses from this list if you test with 0.13.0. > o Any fixes will be applied to 0.13.0, > > You may be fighting 4 different problems: > >(1) VMware remaps the card card name, and causes confusion with pcsc. > >If you could use a real machine that would eliminate this problem for > now. > >(2) You said: > > installed Card Reader driver on fedora with name "ifdokccid.so" > > (my Card Reader is Omnikey CardMan 3121). > > Is this really needed on unix? I thought pcscd would use its own > libccid.so for this reader. If this is a vendor provided library, > what version are you using? > > Can you try without this file. > >(3) You said: > > I've tested OpenSC-0.13.0 MSI on Windows7 and had the same problem in > > pkcs15 initialization as 0.12.2 version! > > This would indicate that your real problem is with opensc most likely > not recognizing the card. (The vendor's window driver works with windows > but the venodor's unix driver may not work with the version of pcscd on > fedora. The introduction of VMware just complicates the problems. > >(4) You said the card is reported: >> ATR: 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4 >> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): >> 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4 >> SmartCafe Expert 3.2 72K > > I don't think this card is supported by OpenSC. In the OpenSC source, any > version > look at the src/libopensc directory. The supported cards all have a module > names card-*.c It might be possible that the iso7816.c directly. > Or you could add an entry in the opensc.conf to force the ATR to be mapped > to a specific supported card. > > > See the discussion from Aug 2011 on the OpenSC -devel lists: > >[opensc-devel] SmartCafe Expert 3.2 72K works fine in some versions but is > an "unsupported card" in other versions. > > It is not clear if this was ever resolved. > > > > > > > > > > > > > > In a previous note you said: >>> Opensc-tool doesn't find the card to show the ATR, because the card reader >>> is not known for it as OMNIKEY. > > > > >> >> No idea. >> > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
On 12/10/2012 10:46 AM, Lukas Wunner wrote: > Hi, > > I've issued pull request #111 which enhances pkcs15-gemsafeV1.c > by two features: > > > (1) Multiple key containers are now supported. > > Previously the code would only make the first certificate found > on the card available to the user. By reverse-engineering the > USB communication of the native Windows driver (Gemalto Classic > Client) it turned out that all certificates are stored in the > same file (3F001604). Up to 12 key containers are supported, > this seems to be the maximum that Gemalto's cards are capable of. > I have a card here which can store up to 10 key containers of which > 2 are allocated. This card works perfectly now. > > The private key and certificate are no longer labeled > DS key / DS certificate, but: > DS key #1, DS key #2, ... / DS certificate #1, DS certificate #2", ... > > @Douglas E. Engert: The code introduced by you with commit > 9468d989cf5f279e11f1551164624c2cd1b25948 is still there, > i.e. the key_ref may be overridden by the opensc.conf card flag, > but it will override the key_ref of *all* keys on the card if > there's more than one. I'm not sure if this functionality is > still necessary. We no longer use these cards. The code in 9468d9 may no longer be needed if you are able to associate the certs and keys. > > > (2) ATR-specific PIN policies are now supported. > > Previously the code would use the PIN policy: > BCD, min length 6, max length 8, padded with 0xFF > However the card I was given uses the following policy: > ASCII, min length 4, max length 8, padded with 0x00 > > I tried to find out, again based on the USB communication of the > native Windows driver, whether the card may be queried for its > PIN policy. But to no avail. More specifically, I tried to find > out if the tries_left can be queried from the card, thinking that > the PIN policy is probably returned in the same APDU. So I > deliberately logged in with the wrong PIN once (=> tries_left=2) > and compared the USB communication to the case when the correct > PIN is entered right away. Turns out there's no difference. > So apparently the tries_left can't be queried from the card > and it seems likely that the PIN policy can't be queried either. > If it can, I don't know where it is stored. > > I then realized that the Windows driver installs two files: > policy.ppc and policyname.ini. Turns out the PIN policy is > encoded in these files. The equivalent to these files would > be if the user could specify a PIN policy in opensc.conf. > > Since that doesn't seem to be possible so far, I modified the > code so that ATR-specific PIN policies may be specified. This > is similar to pkcs15-infocamere.c which uses different card > initialization functions based on the ATR of the card. > > > I also fixed the indentation in gemsafe_detect_card(), > sc_pkcs15emu_gemsafeV1_init() and sc_pkcs15emu_gemsafeV1_init_ex(). > That makes reviewing the patch more difficult, sorry. > > People who are using gemsafeV1 cards in production may want to give > this patch a try. > > Best, > > Lukas > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
Hi, I've issued pull request #111 which enhances pkcs15-gemsafeV1.c by two features: (1) Multiple key containers are now supported. Previously the code would only make the first certificate found on the card available to the user. By reverse-engineering the USB communication of the native Windows driver (Gemalto Classic Client) it turned out that all certificates are stored in the same file (3F001604). Up to 12 key containers are supported, this seems to be the maximum that Gemalto's cards are capable of. I have a card here which can store up to 10 key containers of which 2 are allocated. This card works perfectly now. The private key and certificate are no longer labeled DS key / DS certificate, but: DS key #1, DS key #2, ... / DS certificate #1, DS certificate #2", ... @Douglas E. Engert: The code introduced by you with commit 9468d989cf5f279e11f1551164624c2cd1b25948 is still there, i.e. the key_ref may be overridden by the opensc.conf card flag, but it will override the key_ref of *all* keys on the card if there's more than one. I'm not sure if this functionality is still necessary. (2) ATR-specific PIN policies are now supported. Previously the code would use the PIN policy: BCD, min length 6, max length 8, padded with 0xFF However the card I was given uses the following policy: ASCII, min length 4, max length 8, padded with 0x00 I tried to find out, again based on the USB communication of the native Windows driver, whether the card may be queried for its PIN policy. But to no avail. More specifically, I tried to find out if the tries_left can be queried from the card, thinking that the PIN policy is probably returned in the same APDU. So I deliberately logged in with the wrong PIN once (=> tries_left=2) and compared the USB communication to the case when the correct PIN is entered right away. Turns out there's no difference. So apparently the tries_left can't be queried from the card and it seems likely that the PIN policy can't be queried either. If it can, I don't know where it is stored. I then realized that the Windows driver installs two files: policy.ppc and policyname.ini. Turns out the PIN policy is encoded in these files. The equivalent to these files would be if the user could specify a PIN policy in opensc.conf. Since that doesn't seem to be possible so far, I modified the code so that ATR-specific PIN policies may be specified. This is similar to pkcs15-infocamere.c which uses different card initialization functions based on the ATR of the card. I also fixed the indentation in gemsafe_detect_card(), sc_pkcs15emu_gemsafeV1_init() and sc_pkcs15emu_gemsafeV1_init_ex(). That makes reviewing the patch more difficult, sorry. People who are using gemsafeV1 cards in production may want to give this patch a try. Best, Lukas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Anthony Foiani writes: > Ludovic, greetings -- > > On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau > wrote: >> >> 2012/12/8 Anthony Foiani : >> > Greetings -- >> > >> > I have two small patches which you might want to consider integrating. >> > >> > (And given that I can't get git to do what I want, you probably want >> > to just cherry-pick these, as I suspect I've completely destroyed my >> > repo history...) >> >> You should rebase your patches above OpenSC/OpenSC master. > > Ok, but pardon my git ignorance: I thought that one should never > rebase a tree that will be published and pulled from? Or only if it's > published and someone tries to *base a new tree* off of it? This is somewhat controversial, but from my experience in both open source and large private projects, the key issue is not to rebase branches that other people have made commits on top of, or merged into other branches. I find that it's helpful to rebase branches proposed for merging. The point for me is not so much to have them based off recent master to avoid a merge commit, but to produce the clean series of commits that would have appeared had there been no mistakes. Achieving the goal of not rebasing branches others have derived commits From can be accomplished by not rebasing published branches or having an understanding within the project that branches should not be cross-merged, so that rebasing them is still safe. Even if multitple people commit to a branch, with a little coordination this is not a big deal. pgptpvdzhpga8.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!!
On 12/9/2012 9:56 AM, Ludovic Rousseau wrote: > 2012/12/9 Rns Course : >> Another request of you: >> what's your opinion about windows version of opensc (0.12.2 or 0.13.0) and >> the problem "File not found" in pkcs15 initialization? Why use 0.13.0: o 0.13.0 has many more fixes. o You will get better responses from this list if you test with 0.13.0. o Any fixes will be applied to 0.13.0, You may be fighting 4 different problems: (1) VMware remaps the card card name, and causes confusion with pcsc. If you could use a real machine that would eliminate this problem for now. (2) You said: > installed Card Reader driver on fedora with name "ifdokccid.so" > (my Card Reader is Omnikey CardMan 3121). Is this really needed on unix? I thought pcscd would use its own libccid.so for this reader. If this is a vendor provided library, what version are you using? Can you try without this file. (3) You said: > I've tested OpenSC-0.13.0 MSI on Windows7 and had the same problem in > pkcs15 initialization as 0.12.2 version! This would indicate that your real problem is with opensc most likely not recognizing the card. (The vendor's window driver works with windows but the venodor's unix driver may not work with the version of pcscd on fedora. The introduction of VMware just complicates the problems. (4) You said the card is reported: > ATR: 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4 > Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): > 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4 > SmartCafe Expert 3.2 72K I don't think this card is supported by OpenSC. In the OpenSC source, any version look at the src/libopensc directory. The supported cards all have a module names card-*.c It might be possible that the iso7816.c directly. Or you could add an entry in the opensc.conf to force the ATR to be mapped to a specific supported card. See the discussion from Aug 2011 on the OpenSC -devel lists: [opensc-devel] SmartCafe Expert 3.2 72K works fine in some versions but is an "unsupported card" in other versions. It is not clear if this was ever resolved. In a previous note you said: >> Opensc-tool doesn't find the card to show the ATR, because the card reader >> is not known for it as OMNIKEY. > > No idea. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pam_pkcs11 with many certificates on a single token
Hello, Here is my patch (actually, 2 patches that depend if the patch concerns only the error 2328 (patch 1) or the whole block processing the return value of verify_certificate() (patch 2)). Thanks for your fast answer. Hope my patches could help, Regards, Frédéric Combeau. -Message d'origine- De : Ludovic Rousseau [mailto:ludovic.rouss...@gmail.com] Envoyé : lundi 10 décembre 2012 13:49 À : COMBEAU Frederic 150138 Cc : opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] pam_pkcs11 with many certificates on a single token 2012/12/10 : > Hello, Hello, > I use pam_pkcs11 0.6.8 with libcurl but without nss. My tokens works fine but > they can contain 4 or 5 certificates (with corresponding rsa keys). > > My certificates are not all from the same PKI, so they are not certified by > the same ACs. > > The problem I encounter with pam_pkcs11 is that if the first certificate it > tries to verify is not certified by ACs I installed on my workstation, I got > an error 2328 because verify_certificate() return -4 and pam_pkcs11 stops > (line 584 of src/pam_pkcs11/pam_pkcs11.c : goto auth_failed_nopw;), not > trying to verify others certificates in my token. I do not really want to > install all ACs (including CRLs, ...) of my certificates of my token on every > workstations. > > I tried to add a "continue;" in pam_pkcs11.c in the switch test for the error > 2328 : if verify_certificate() returns -4, pam_pkcs11 prints the error > message "error 2328: ..." and with the continue command, pam_pkcs11 continues > to process the next certificates and everything works great. > > Maybe I missed something that explains why pam_pkcs11 stops processing > certificates if the verification of a certificate returns -4. I guess it is just a bug or a missing feature. Can you send me a patch (or, better, a github pull request) so I can fix the problem? The project is at https://github.com/OpenSC/pam_pkcs11 Thanks -- Dr. Ludovic Rousseau patch_pam_pkcs11-0.6.8_error2328-1.patch Description: patch_pam_pkcs11-0.6.8_error2328-1.patch patch_pam_pkcs11-0.6.8_error2328-2.patch Description: patch_pam_pkcs11-0.6.8_error2328-2.patch ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pam_pkcs11 with many certificates on a single token
2012/12/10 : > Hello, Hello, > I use pam_pkcs11 0.6.8 with libcurl but without nss. My tokens works fine but > they can contain 4 or 5 certificates (with corresponding rsa keys). > > My certificates are not all from the same PKI, so they are not certified by > the same ACs. > > The problem I encounter with pam_pkcs11 is that if the first certificate it > tries to verify is not certified by ACs I installed on my workstation, I got > an error 2328 because verify_certificate() return -4 and pam_pkcs11 stops > (line 584 of src/pam_pkcs11/pam_pkcs11.c : goto auth_failed_nopw;), not > trying to verify others certificates in my token. I do not really want to > install all ACs (including CRLs, ...) of my certificates of my token on every > workstations. > > I tried to add a "continue;" in pam_pkcs11.c in the switch test for the error > 2328 : if verify_certificate() returns -4, pam_pkcs11 prints the error > message "error 2328: ..." and with the continue command, pam_pkcs11 continues > to process the next certificates and everything works great. > > Maybe I missed something that explains why pam_pkcs11 stops processing > certificates if the verification of a certificate returns -4. I guess it is just a bug or a missing feature. Can you send me a patch (or, better, a github pull request) so I can fix the problem? The project is at https://github.com/OpenSC/pam_pkcs11 Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Food for thought on C coding style
Thanks a lot for this really interesting share. This will help me improve my code quality for sure! On Mon, Dec 10, 2012 at 11:26 AM, Martin Paljak wrote: > Hello, > > https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard > > Martin > ___ > 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
[opensc-devel] pam_pkcs11 with many certificates on a single token
Hello, I use pam_pkcs11 0.6.8 with libcurl but without nss. My tokens works fine but they can contain 4 or 5 certificates (with corresponding rsa keys). My certificates are not all from the same PKI, so they are not certified by the same ACs. The problem I encounter with pam_pkcs11 is that if the first certificate it tries to verify is not certified by ACs I installed on my workstation, I got an error 2328 because verify_certificate() return -4 and pam_pkcs11 stops (line 584 of src/pam_pkcs11/pam_pkcs11.c : goto auth_failed_nopw;), not trying to verify others certificates in my token. I do not really want to install all ACs (including CRLs, ...) of my certificates of my token on every workstations. I tried to add a "continue;" in pam_pkcs11.c in the switch test for the error 2328 : if verify_certificate() returns -4, pam_pkcs11 prints the error message "error 2328: ..." and with the continue command, pam_pkcs11 continues to process the next certificates and everything works great. Maybe I missed something that explains why pam_pkcs11 stops processing certificates if the verification of a certificate returns -4. Thanks for any helps you could give me. Regards. Frédéric Combeau. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
2012/12/10 Anthony Foiani : > Ludovic, greetings -- > > On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau > wrote: >> >> 2012/12/8 Anthony Foiani : >> > Greetings -- >> > >> > I have two small patches which you might want to consider integrating. >> > >> > (And given that I can't get git to do what I want, you probably want >> > to just cherry-pick these, as I suspect I've completely destroyed my >> > repo history...) >> >> You should rebase your patches above OpenSC/OpenSC master. > > Ok, but pardon my git ignorance: I thought that one should never > rebase a tree that will be published and pulled from? Or only if it's > published and someone tries to *base a new tree* off of it? That is what I thought also. But it is far easier to review a patch when the history is clean. >> > https://github.com/tkil/OpenSC/commit/0c4a2e0c4063f31bc41c34e45869b9a9e7ca41d7 >> > This uses "dir local" settings to configure Emacs indentation correctly. >> >> I don't think that an Emacs configuration file should be added to the >> OpenSC source code. > > Hm. Why not? It would ensure that emacs users have their style set > appropriately for this project, and shouldn't affect anyone else in > any way. > > In my own use case, I work on 3-4 projects in the same emacs session, > and each one has different indentation settings. dir-local settings > seem the easiest way to assign a style per directory (tree). > >> You should keep this change in your own branch. > > And for my second question of git ignorance: how can I maintain "my > own branch", when merging upstream into a branch is discouraged? Or > do I misunderstand the tone of the log comments when trying to check > in such a merge? Or just keep the file.dir-locals.el out of git. I have no objection to add this file. I do not use Emacs myself. I see it can help code quality so unless someone objects I will merge it upstream. Please submit a pull request. >> > https://github.com/tkil/OpenSC/commit/599bd1e6c906af63eb379c866076f98a91654cb2 >> > I spotted an inconsistency in how the option argument pointers were >> > initialized; this fixes it (to make it more consistent). >> >> Not a bug but the code would be nicer. > > For whatever it's worth, my understanding is that uninitialized global > variables are actually allocated as a part of program runtime, and are > initialized to zero at that point. *Initialized* global variables, > however, are stored in the binary itself, even if the initializer is > zero. > > So as a matter of style, it might be better to leave all those > pointers uninitialized. (This was a big stink on the linux-kernel > mailing list a few years back.) > > On the other hand, I don't know if this behavior is true across all > platforms, and the space/time cost in this case is trivial. > >> Can you create a branch from OpenSC/OpenSC master with only this patch >> and ask for a Pull Request? > > I'll try. :) Every time I try to use git for anything fancier than > an svn-replacement, I seem to get burned... > > In this case, it looks like I'll have to fork the OpenSC version > (instead of the CardContact version), then branch in my new fork, > commit this change, and then request a pull of my new branch on the > new fork? (Not complaining about amount of work, just trying to make > sure I have the flow correct.) Now merged upstream. Merging a pull request from github adds a "merge pull request" commit. The history is then not very nice (linear) but I don't know a better way using the github web interface. Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Food for thought on C coding style
Hello, https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Frank, greetings -- On Mon, Dec 10, 2012 at 12:23 AM, Frank Morgner wrote: > Your editor should be intelligent enough to guess the right settings. Why have the editor guess, when it could know the right answer? > For vim I recently found this plugin > http://www.vim.org/scripts/script.php?script_id=4251 There is a similar feature for emacs (c-guess and friends). I am impressed by their cleverness, but it seems better to specify than to guess (with the chance of guessing wrongly). And it's not just tabs-vs-spaces, but also a human judgement as to whether those tabs are intended to represent 4 spaces or 8. No good answers. I just offered the directory-wide settings for emacs as a way to reduce my pain, and possibly to avoid patch submissions with incorrect indentation. Anyway. If Ludovic doesn't want it around, then that's fine by me; I'll find another way to make sure that I use the correct style. :) Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
