Re: [opensc-devel] Changed certificate on opensc-project.org
Dear Martin, opensc-project.org SSL certificate expired (kind of suddenly, there should have been a reminder but that did not arrive for some reason), the checksums of the new one are: MD5: 68786c3e0cfe44e31d6c789e767605d5 SHA1: d7af30e8dfd9b6433353999f24e5dbb74132a988 Nice to see you on board. Could you have a look at our previous posts and confirm that : 1) The OpenSC project is not owned by you but by the community at large. 2) That you are a system administrator and developper. As such, you admit to serve the community. The reason behind is that we would like to avoid OpenSC becoming another project like CCID or Apple Tokend, where one or two persons lock down commits. Please have a look at this page: http://smartcardservices.macosforge.org/trac/wiki/team CCID Engineering • Lead: Ludovic Rousseau • Dev: Ludovic Rousseau PCSCD Engineering • Lead: Ludovic Rousseau • Dev: Ludovic Rousseau I am worried that a a small team of committers linked to companies lead to interest conflicts. For example, tokend has an outdated CCID, an outdated libUSB and only some vendor drivers are updated, including Gemalto. Furthermore, you don't seem to answer our emails. Which leads me to believe that you are acting as an owner and not as a system administrator. Please confirm by writing that you are not OpenSC owner. And please don't answer us something like go fork, we are not going to do it. When the project was handed over by Andreas, it was a community and shall remain. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GlobalPlatform and OpenSC
2012/3/22 Anders Rundgren anders.rundg...@telia.com Somewhat related to the OpenSC organization discussions: http://www.globalplatform.org/documents/Consumer_Centric_Model_White_PaperMar2012.pdf I must confess I don't understand a thing of this, neither the business model, the consumer centric concept, or how it integrates in phones that doesn't permit changes in the internals except through routing or jail-breaking. my view: all you need is authentication. their view: no, that is only the start, they want to have applications deployed on tokens, security policies, and whatnot. at least they realize people buy their own smartphones and use them. now they want people to buy their secure tokens and use them, and have a huge ecosystem build on top of that. well, if that is a sign towards more compatiblitiy: +1 but in general I still think complex on card systems are a failed model. all you need is authentication, and the rest can be build much better, much cheaper, much faster, much more secure as an online system. Andreas Anders On 2012-03-22 10:33, Alon Bar-Lev wrote: On Thu, Mar 22, 2012 at 12:03 AM, Peter Stuge pe...@stuge.se wrote: Alon Bar-Lev wrote: I will try again. Thanks! It really helps! I am glad! Well, let's agree we do not agree... :) At no point in time I argue that the gerrit is not a good tool, I argue the methodology. Anyway, just last note I want to make... OpenSC is by far *NOT* a security project. Yes, that may sound surprising... :) OpenSC deals with security subject, that's true... hardware cryptography. But its origin mission was to provide access (USABILITY) to none Windows (+ none proprietary) users to hardware cryptography, PKCS#15 and partially by reverse engineering. If we want OpenSC to be security project, we should probably rewrite the whole thing from scratch. With different priorities, the code will probably be completely different feature set will be smaller, and the quality of the code will be higher, thus also the cost of implementation and maintenance. Few years back, when I tried to push OpenSC enabled tokens to enterprises, I found that I just cannot do that, mainly because of this reason. I don't see this happening without sponsor and some full time developers. Maybe this is another issue that differentiate our views. I think there is a great value in current state of OpenSC to allow people to [at least] use hardware cryptography, even if this is not the perfect implementation, keeping it flexible enough to enlarge the cycle of devices and users. Apart of the value of people can actually use their hardware, this implementation will allow in future the necessary low level details in order to do the rewrite. Alon. ___ 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 mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PINDAD fix
Dear all, Here is outlined a PINPAD fix (read second comment): http://sourceforge.net/tracker/?func=detailatid=2247688aid=3489002group_id=553887 I would like to know your opinion about the proposed solution. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changed certificate on opensc-project.org
Jean-Michel, Le 23 mars 2012 08:58, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : Dear Martin, opensc-project.org SSL certificate expired (kind of suddenly, there should have been a reminder but that did not arrive for some reason), the checksums of the new one are: MD5: 68786c3e0cfe44e31d6c789e767605d5 SHA1: d7af30e8dfd9b6433353999f24e5dbb74132a988 Nice to see you on board. Could you have a look at our previous posts and confirm that : 1) The OpenSC project is not owned by you but by the community at large. 2) That you are a system administrator and developper. As such, you admit to serve the community. It is not nice to hijack a thread and change the discussion. The reason behind is that we would like to avoid OpenSC becoming another project like CCID or Apple Tokend, where one or two persons lock down commits. Please have a look at this page: http://smartcardservices.macosforge.org/trac/wiki/team CCID Engineering • Lead: Ludovic Rousseau • Dev: Ludovic Rousseau PCSCD Engineering • Lead: Ludovic Rousseau • Dev: Ludovic Rousseau I am worried that a a small team of committers linked to companies lead to interest conflicts. For example, tokend has an outdated CCID, an outdated libUSB and only some vendor drivers are updated, including Gemalto. I do not remember having seen _ANY_ patch from you regarding the http://smartcardservices.macosforge.org/ project. You have to understand that free software projects (in a large part) are do-ocracy and not democracy. The people doing things decide how they do it. If you want to get a commit write access you shall first provide good patches and work. It does not work in the reverse order. If you are not happy with what Apple provides in the OS then contact Apple, not me or this mailing list. Furthermore, you don't seem to answer our emails. Which leads me to believe that you are acting as an owner and not as a system administrator. Please confirm by writing that you are not OpenSC owner. And please don't answer us something like go fork, we are not going to do it. When the project was handed over by Andreas, it was a community and shall remain. You cannot _require_ anything from volunteers. And you are very rude trying to do that. Regards, -- 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] Changed certificate on opensc-project.org
Dear Ludovic and all, You have to understand that free software projects (in a large part) are do-ocracy and not democracy. The people doing things decide how they do it. If you want to get a commit write access you shall first provide good patches and work. It does not work in the reverse order. Over the past years, we saw many Apple projects turning into semi-private project. Another example is CUPS. Of course, CUPS systems are available in Linux. But drivers are old and Apple always provides updated drivers. The way Apple controls open-source projects is that there is a limited number of people with commit access, which are their employees or contractors. Also, the fact that you may ask money to review code and commit it to libccid or pcsc-lite strikes me. Of course, you accept any bug fix for free. But large companies have to pay. This is probably why some companies prefer to publish a libccid fork and not commit to main trunk. Therefore looking at the current OpenSC organization, I can only think about the way things evolved at pcsc-lite and tokend. We all agree here that OpenSC is not a semi-closed project and we ask you and Marin to confirm that: 1) The OpenSC project is owned by the community at large, not one or two individuals. 2) That Martin and You are system administrators and developers. As such, you admit to serve the community. You are not the owners. This is rather simple! Why should it be rude? We don't want OpenSC to turn into another pcsc-lite and/or tokend, please understand. Until you don't write Yes I agree to both statements, there will be a believe in the community that you are trying to take over. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changed certificate on opensc-project.org
What exactly are you trying to achieve? Dear Emanuelle, In the past, main OpenSC developers used to have write access to the main trunk or at least to their development. This is no longer the case. The new collaboration tools like GIT are used to limit the power of the main developers. Over the past months, OpenSC slowly evolved into a project like pcsc-lite and tokend: * Only one or two members control commits. * As a result, they are overwhelmed with work and cannot keep on reviewing patches. Some patches have been around for 6 months. * pcsc-lite project is asking some companies to pay for review and I am worried about that. Also I don't trust the way tokend is managed, as I can see activity around Gemalto drivers, not elsewhere. I know several companies releasing their own libccid and this is not good. So to make it clear, I don't trust Ludovic Rousseau to defend our interest, although he is a good developer. For example, there never was a speed detection algorithm in libccid, so that some smartcard readers do initialize at low speed. But some Gemalto readers do initialize thanks to some libccid hack in code. Apple does exactly the same when some CUPS drivers are not comparable in Mac OS X and other systems. This is rather subtle, but I begin to understand some marketing techniques. * For me the next step is a company like Apple or Gemalto taking over OpenSC. Some reviewers are already Gemalto contractors, this is not a secret. when reading your statement Emmanuele, we understand that you are serving the community. Thanks. Now we are asking Ludovic and Martin to make a statement where the they confirm a) and b): 1) The OpenSC project is owned by the community at large, not one or two individuals. 2) Martin and Ludovic are system administrators and developers. As such, you admit to serve the community. They are not the owners. Is that SO hard to write? Is that being rude? I don't believe so. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Mon, Mar 19, 2012 at 13:08, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: OpenSC copyright belongs to the group of people who wrote OpenSC, which is all of us. It does not belong to any company and an individual granting rights to other individuals. In legal terms, *copyright* on OpenSC belongs to the authors who have contributed code, and/or marked it down in source code. The fact that other, unknown persons (not established in source code as copyright owners) have code in OpenSC source tree is also known, as there is no legal body (foundation, like Gnome or GNU or similar) that would govern licensing in OpenSC. This has also helped free some source code that has been grabbed by some companies and turned into their offerings, without giving source code. Thus everybody are free to use the source code on the same terms, which is mostly LGPL (there are exceptions, like the Tokend code wihich is not LGPL as it is derived from Apple source code etc etc) To be more precise: Peter, Ludovic and Martin do not have any legal right to establish rules over OpenSC project. Especially if these rules go in the direction of more bureaucracy. We have to accept collaboration whenever possible. The only legal right is what is written in LGPL or other licenses and I'm pretty sure that nobody wants to change that. But yes, you are right. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Ownership issue and consequences on OpenSC project
Le vendredi 23 mars 2012 à 13:19 +0200, Martin Paljak a écrit : In legal terms, *copyright* on OpenSC belongs to the authors who have contributed code, and/or marked it down in source code. The fact that other, unknown persons (not established in source code as copyright owners) have code in OpenSC source tree is also known, as there is no legal body (foundation, like Gnome or GNU or similar) that would govern licensing in OpenSC. This suits me very well. This means that OpenSC project belongs to the group of people who contributed source code. Each contributor, even with one line of code, is legally an owner. This is called joint-ownership by law. Thus everybody are free to use the source code on the same terms, which is mostly LGPL (there are exceptions, like the Tokend code wihich is not LGPL as it is derived from Apple source code etc etc) Sure. Another consequence is that, to some extent, if the community is asking for more freedom to contribute, we shall find a way to collaborate. For example, if you are the owner of a 1% of a car would like to use it, you may request free access to the car. Free software is no difference. Of course, I don't mean everyone should have commit access to the repository, but at least every recognized developer should be able to: * Be listed as member on the GIThub main project with Martin and Ludovic. * Have commit access to the main repository. There are public discussions before commit. * Decide in common about important issue, like release process and schedule. Understand, this is a right for democracy where we discuss about important issues. Basically, this is as it was before moving to GIT even if we keep GIT. Martin, will you agree that also? Kind regards, Jean-Michel -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Simple End User Joe here, A suggestion for all concerned: Please try to forget personal differences, and solve the problem ahead. You are all very bright, you do awesome work, we all endlessly admire you and thank you for all you have achieved so far. But. For me it seems that there IS a problem with development procedures, project structure AND communication. Take a look at your roadmap page. The fact that you are late is okay, this is an open source project after all. But 6 months worth of patches which cannot be reviewed is something which should something be done about. I would need no further support for the request of dropping gerrit or whatsnot than no one actually operates it. Okay, I understand, you are at the top of food chain are concerned with quality. And you simultaneously don't have enough time to review patches. Both are correct and understandable. And there is a way out of this situation. Require assurance of the stuff is working before even taking a look at it: unit tests and/or ack of an established developer, maybe even an end user report confirming the thing is working. Or formal verification with frama-c. Or whatever you read about in CC part 3 or the strike fighter air vehicle coding standards. But if the requirements are met, please take a quick look at it and commit it. And fast. Because if you raise the bar enough, you won't have much junk to sort out and you already have reasonable assurance. And please talk to each other. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changed certificate on opensc-project.org
2012/3/23 Jean-Michel Pouré - GOOZE jmpo...@gooze.eu: In the past, main OpenSC developers used to have write access to the main trunk or at least to their development. Even minor ones, such as myself. This is no longer the case. The new collaboration tools like GIT are used to limit the power of the main developers. I do not think so. Anybody is free to write code and share it. * Only one or two members control commits. * As a result, they are overwhelmed with work and cannot keep on reviewing patches. Some patches have been around for 6 months. Please understand that nobody needs to be a committer in order to be a reviewer. Anyone can be a reviewer, and Gerrit is meant to make that easier. I think that my own position is fairly close to Peter's on this matter. If I had seen code reviews on this list, and their iterations had output reviewed code that did not make it into trunk, I'd agree with you that limited commit rights are a bottleneck. Since I haven't, I can't really say that committers are the bottleneck. I am sure that there are many good examples of this notion. I'll share the first example that comes to my mind, which is the Illumos development process. You can see this going on at https://www.listbox.com/member/archive/182179/=now (even without advanced tools like Gerrit). I will not comment on pcsc-lite, as I don't know enough about it, but I agree with everything that Martin has written today on this list. * For me the next step is a company like Apple or Gemalto taking over OpenSC. Some reviewers are already Gemalto contractors, this is not a secret. This is more of a conspiracy theory than anything else, IMVHO. I might even comment, tongue-in-cheek, that if nobody except Gemalto contractors is interested in reviewing code, then maybe that would be a reasonable course of action. ;) when reading your statement Emmanuele, we understand that you are serving the community. Thanks. I actually scratched my own itch. It happened to be the same itch of a larger community, and after that I did agree to doing some work to benefit other community members but not myself. That is all. Now we are asking Ludovic and Martin to make a statement where the they confirm a) and b): 1) The OpenSC project is owned by the community at large, not one or two individuals. I think that your notion of ownership, as you explained by way of the car example, is misleading at best. A FLOSS project such as this is more concerned with stewardship than ownership, as far as I can see. Best regards, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Although OpenSC may be in a bit of s*** right now, that's a gentle breeze compared to what is happening in the outside world. There will be a war between a set of very divided European SC-vendors against three gaint US corportations who are rolling out virtual smart cards like: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T Conclusion: smart cards will increase in importance but the reliance on external middleware will slowly but surely go away. Maybe even the SC- industry some day comes to its senses and actually provides a standard card? Users of iPhone won't have to bother about drivers and the phone will nicely dock to the Mac as well. My only fear is that The Big Three in the absence of any standard will come up with three unique solutions. Anders On 2012-03-23 14:17, Magosányi, Árpád wrote: Simple End User Joe here, A suggestion for all concerned: Please try to forget personal differences, and solve the problem ahead. You are all very bright, you do awesome work, we all endlessly admire you and thank you for all you have achieved so far. But. For me it seems that there IS a problem with development procedures, project structure AND communication. Take a look at your roadmap page. The fact that you are late is okay, this is an open source project after all. But 6 months worth of patches which cannot be reviewed is something which should something be done about. I would need no further support for the request of dropping gerrit or whatsnot than no one actually operates it. Okay, I understand, you are at the top of food chain are concerned with quality. And you simultaneously don't have enough time to review patches. Both are correct and understandable. And there is a way out of this situation. Require assurance of the stuff is working before even taking a look at it: unit tests and/or ack of an established developer, maybe even an end user report confirming the thing is working. Or formal verification with frama-c. Or whatever you read about in CC part 3 or the strike fighter air vehicle coding standards. But if the requirements are met, please take a quick look at it and commit it. And fast. Because if you raise the bar enough, you won't have much junk to sort out and you already have reasonable assurance. And please talk to each other. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. ___ 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] Changed certificate on opensc-project.org
Dear Emanuele, Please understand that nobody needs to be a committer in order to be a reviewer. Anyone can be a reviewer, and Gerrit is meant to make that easier. Sure. If all developers had the ability to vote on Gerrit and apply patches, this would solve many problems. Is that the case already? Please advise. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Getting lost compiling OpenSC and tokend for Mac OS X 10.7
Dear Martin, Last time I checked, it worked flawlessly on fresh/clean 10.6 with the given instructions. You are right, this is better than my way compiling by hand. We installed a dedicated Mac OS X station for Jenkins and I just switched back from 10.7 to 10.6 (Snow Leopard). This should work now.Thanks. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Hello, On Fri, Mar 23, 2012 at 15:17, Magosányi, Árpád m4g...@gmail.com wrote: And you simultaneously don't have enough time to review patches. Both are correct and understandable. And there is a way out of this situation. Require assurance of the stuff is working before even taking a look at it: unit tests and/or ack of an established developer, maybe even an end user report confirming the thing is working. Or formal verification with frama-c. Or whatever you read about in CC part 3 or the strike fighter air vehicle coding standards. But if the requirements are met, please take a quick look at it and commit it. And fast. Because if you raise the bar enough, you won't have much junk to sort out and you already have reasonable assurance. True. The trick is having a system that works and also helps to achieve the target of having more people *actually* looking at code and some testing (like automatic building) done before even considering ack-ing something. But lagging on processing any flow is of course not really acceptable. Given that resources are low, automation should help. Like Gerrit och Jenkins. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. There is #opensc on freenode, but people on opensc-devel have most of the time to date been against such communication, either because of timezone differences or just because it is very difficult for a handful of otherwise busy people to find that time (I guess). But a bi-weekly recap would be good idea to have. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Sun, Mar 18, 2012 at 00:30, Viktor Tarasov viktor.tara...@gmail.com wrote: - replication in gerrit do not working. Should we manually push the perfect commits from gerrit's repo to staging? (In the github's pull requests the commits are also perfects, almost perfect.) Fetching github Fetching gerrit Fetching master To g...@github.com:OpenSC/OpenSC.git ! [rejected]master/staging - staging (non-fast-forward) error: failed to push some refs to 'g...@github.com:OpenSC/OpenSC.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. To g...@github.com:OpenSC/OpenSC.git Github mirror was supposed to be a plain (one way) mirror, meaning that things that go through gerrit are published on github and github pull requests put to Gerrit, but merging both to gerrit and github causes expected different trees. Fixing this requires some effort. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Hi, On 03/23/2012 05:48 PM, Martin Paljak wrote: The trick is having a system that works and also helps to achieve the target of having more people *actually* looking at code and some testing (like automatic building) done before even considering ack-ing something. But lagging on processing any flow is of course not really acceptable. Given that resources are low, automation should help. Like Gerrit och Jenkins. Yes, but if you cannot sustain that infrastructure, then it is a stumbling block rather than a help. Maybe it could be solved by enabling more access to it. Or if this is not the way to go, than you can relay on people building and reporting back by hand. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. There is #opensc on freenode, but people on opensc-devel have most of the time to date been against such communication, either because of timezone differences or just because it is very difficult for a handful of otherwise busy people to find that time (I guess). doodle would help on that: http://doodle.com/ But a bi-weekly recap would be good idea to have. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Magosányi, Árpád wrote: 6 months worth of patches which cannot be reviewed This is simply not true. *Anyone* can register on Gerrit and review, and *all* review is a helpful contribution! The problem is not that the code can not be reviewed, but that noone is doing review. Anyone can do it. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/23/2012 07:10 PM, Peter Stuge wrote: Magosányi, Árpád wrote: 6 months worth of patches which cannot be reviewed This is simply not true. *Anyone* can register on Gerrit and review, and *all* review is a helpful contribution! The problem is not that the code can not be reviewed, but that noone is doing review. Anyone can do it. Nice. I can add some things to that: 1. I'm sure that there are patch owners, who would ask someone to review their patch if this would be communicated to them. 2. Okay, I'm here to review one patch or two if it helps the community. My first question is where can I find the patch reviewing guidelines, including practical usage information on this gerrit thingie, and the guidelines on what is acceptable. And be aware that I am so dumb to programming that I'm doing it in Java, and even that way I'm the only one accepting my patches. But I can compile and test things if it helps, and have a handful of smart cards and tokens at hand. 3. If you would actively seek contributors, you might find someone who can do that with some quality. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Hello, On Tue, Feb 21, 2012 at 16:46, Douglas E. Engert deeng...@anl.gov wrote: It does not define a load key or any finalize commands which would be needed by a production card management system. I don't know about PIV internals, but maybe the finalize step is automatic or not needed at all (meaning that key re-generation is allowed, assuming you want to live without certificates or something similar) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Hello Anders, On Tue, Feb 21, 2012 at 19:40, Anders Rundgren anders.rundg...@telia.com wrote: I have played with the idea of creating a secure stack-machine for performing arbitrary cryptographic operations on result-data but I couldn't figure out how this would work without introducing vulnerabilities. :-( This sounds really interesting. What kind of problems did you encounter? Do you have any reading material on this? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PINDAD fix
On Fri, Mar 23, 2012 at 10:44, Jean-Michel Pouré - GOOZE
jmpo...@gooze.eu wrote:
Here is outlined a PINPAD fix (read second comment):
http://sourceforge.net/tracker/?func=detailatid=2247688aid=3489002group_id=553887
I would like to know your opinion about the proposed solution.
The comment points out a possible problem with pintest test program,
which should not affect the overall functioning of the pinpad, for
example through PKCS#11.
From the comment:
The problem is that getpass will not return empty string if return
key is pressed on the computer keyboard.
From getpass(3) on Debian 6:
The function getpass() returns a pointer to a static buffer
containing (the first PASS_MAX bytes of) the password without the
trailing new‐line, terminated by a null byte ('\0').
So the input should be a null string with getpass on Debian. But the
man page also tells that This function is obsolete. Do not use it.
Martin
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 3/23/2012 11:48 AM, Martin Paljak wrote: Hello, On Fri, Mar 23, 2012 at 15:17, Magosányi, Árpádm4g...@gmail.com wrote: And you simultaneously don't have enough time to review patches. Both are correct and understandable. And there is a way out of this situation. Require assurance of the stuff is working before even taking a look at it: unit tests and/or ack of an established developer, maybe even an end user report confirming the thing is working. Or formal verification with frama-c. Or whatever you read about in CC part 3 or the strike fighter air vehicle coding standards. But if the requirements are met, please take a quick look at it and commit it. And fast. Because if you raise the bar enough, you won't have much junk to sort out and you already have reasonable assurance. True. The trick is having a system that works and also helps to achieve the target of having more people *actually* looking at code and some testing (like automatic building) done before even considering ack-ing something. But lagging on processing any flow is of course not really acceptable. Given that resources are low, automation should help. Like Gerrit och Jenkins. Another issues with this project is many of the modifications can only be tested by a subset of developers (maybe only one) who have the cards that can use the modification. SM - I don't have any cards that can use this, others may. ePass2300 - GOOZE was willing to sending them out to developers, I don't know how many may have them, and if they do have they voted? It worked for me and I voted +1. (I think I voted.) ECDH/C_Derive - One needs a smart card that can do ECC key derivation. I have some test cards and some demo cards from NIST that can do this, The NIST people were using the mods for testing with thunderbird, so there are at least 2 of us. What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! Many can compile and verify code does not cause other problems, but I suspect most developers will wait for the next pre release before doing and testing at all. That what has happened in the past. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. There is #opensc on freenode, but people on opensc-devel have most of the time to date been against such communication, either because of timezone differences or just because it is very difficult for a handful of otherwise busy people to find that time (I guess). But a bi-weekly recap would be good idea to have. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov 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] Upgrading aPass2003 Firmware to PIV
On 3/23/2012 2:59 PM, Martin Paljak wrote: Hello, On Tue, Feb 21, 2012 at 16:46, Douglas E. Engertdeeng...@anl.gov wrote: It does not define a load key or any finalize commands which would be needed by a production card management system. Martin, You really are catching up on your mail! I don't know about PIV internals, but maybe the finalize step is automatic or not needed at all (meaning that key re-generation is allowed, assuming you want to live without certificates or something similar) That may be true. The PIV specs leave the card initialization commands up to the vendor, and the intent of the OpenSC PIV driver was to provide user access to the card which is standardized. Thus I have not dealt with card initialization, accept to produce cards for testing. Martin -- Douglas E. Engert deeng...@anl.gov 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] Ownership issue and consequences on OpenSC project
On Fri, Mar 23, 2012 at 22:16, Douglas E. Engert deeng...@anl.gov wrote: ECDH/C_Derive - One needs a smart card that can do ECC key derivation. I have some test cards and some demo cards from NIST that can do this, The NIST people were using the mods for testing with thunderbird, so there are at least 2 of us. Working as in working in a test or working with my software X in environment Z. For example, I have a card that can do ECC derivation, but only a test script to test it against and it is not a PIV card... What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! For non-obvious things, a did not break anything I use is as valuable as works for me as well. In between lies a healthy amount of don't know what it is but it looks weird kind of review, which can filter also many things. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/23/2012 09:16 PM, Douglas E. Engert wrote: Another issues with this project is many of the modifications can only be tested by a subset of developers (maybe only one) who have the cards that can use the modification. I am more optimistic than that. If it is made clear that the patch submitter's role to find testers and ask them to ack the patch on gerrit, then it might even happen. In a lot of cases the developer knows some guys with the hardware in question. As an example I am one of the guys who have received an epass from gooze for free. If they would drop me please test this notice, I would even feel obligued to help out. This whole story is mostly about communication. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] gerrit - howto?
I have registered to gerrit, because saying stuff is one thing, doing it is another. I guess I am supposed to verify and/or review. Which is what, and how? I have choosen Change I1e6f787d to experiment with, which is a nice oneliner. Some guy have changed an email address in a comment to his own. I believe reviewing means I should take a look at the patch to ensure that it is up to the standards. Well, I don't know the standards still, but as it is in the same form as the previous, I would think it is. so my verdict here is PASS. Also I believe verifying normally means testing the patch. But in this case maybe verifying the authenticity of the contact change would be the correct way. So I write an email to the old guy, and to the email address in the same source code which is from the same domain, and to some guy I guess is associated with the driver in question. If any one says yes and none says no, then I will push the verify button. Is it what someone supposed to do with this gerrit thingie? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 3/23/2012 3:29 PM, Martin Paljak wrote: On Fri, Mar 23, 2012 at 22:16, Douglas E. Engertdeeng...@anl.gov wrote: ECDH/C_Derive - One needs a smart card that can do ECC key derivation. I have some test cards and some demo cards from NIST that can do this, The NIST people were using the mods for testing with thunderbird, so there are at least 2 of us. Working as in working in a test or working with my software X in environment Z. The NIST Thunderbird tests required changes to nss to handle EC derivation correctly, and can call opensc-pkcs11.so to decrypt e-mail using a PIV card. I was able to use these nss mods as well. If interested, I can find the references next week.) For example, I have a card that can do ECC derivation, but only a test script to test it against and it is not a PIV card... Great. The card driver would also need modifications I assume. Since The PIV could only do ECDH1-COFACTOR-DERIVE with a KDF_NULL, if your card can do more, then additional code would be needed. The point being the ECDH code so far does not implement a full ECDH, but only that part that could be tested. Attached is a test script that uses the certificate from one card, and derives a key using a second card. When run the other way, both will derive the same key. What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! For non-obvious things, a did not break anything I use is as valuable as works for me as well. In between lies a healthy amount of don't know what it is but it looks weird kind of review, which can filter also many things. Martin -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 #!/bin/bash # # test OpenSC pkcs11 with ECDH to derive a key # using the pub key from the certificate # of another card. # Doing the equivement operation using # the two cards should yeild the same derived key. # # $1 is ID of the EC key on the card in the reader. #03 is the Key Managment key, but other keys #and certificates may be obtrained using the #the history object. # # $2 is the PEM encoded certificate that the othercard #will will use to do its derivation. # export LD_LIBRARY_PATH=/opt/smartcard/lib export PATH=/opt/smartcard/bin:$PATH export MODULE=/opt/smartcard/lib/opensc-pkcs11.so SLOT=1 P11=pkcs11-tool --slot $SLOT --module $MODULE TMP=/tmp/derive.$$ OUT= O= while test $# -gt 0 ; do arg=$1 case $arg in -o) shift OUT=-o $1 shift ;; -O) shift O=-O ;; -*) echo Unknow option $1 exit 1 ;; *) echo Found $1 break ;; esac done if [ $# -ne 2 ] ; then echo two paramerters are required exit 2 fi if [ ! -f $2 ] ; then echo $2 not found exit 1 fi openssl x509 -noout -in $2 -pubkey \ | openssl ec -pubin -outform DER $TMP.other.pubkey.der $P11 -l --derive -m ECDH1-COFACTOR-DERIVE $O \ -d $1 -i $TMP.other.pubkey.der $OUT ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Martin, Le 23 mars 2012 18:17, Martin Paljak mar...@martinpaljak.net a écrit : Hello, On Sun, Mar 18, 2012 at 00:30, Viktor Tarasov viktor.tara...@gmail.com wrote: - replication in gerrit do not working. Should we manually push the perfect commits from gerrit's repo to staging? (In the github's pull requests the commits are also perfects, almost perfect.) Fetching github Fetching gerrit Fetching master To g...@github.com:OpenSC/OpenSC.git ! [rejected] master/staging - staging (non-fast-forward) error: failed to push some refs to 'g...@github.com:OpenSC/OpenSC.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. To g...@github.com:OpenSC/OpenSC.git Github mirror was supposed to be a plain (one way) mirror, meaning that things that go through gerrit are published on github and github pull requests put to Gerrit, but merging both to gerrit and github causes expected different trees. Fixing this requires some effort. I think I am the/one of responsible for this problem. Since gerrit was not working for me I merged new code on github. Sorry for the mess. Are pull request for OpenSC/OpenSC on github sent to gerrit automatically as documented in [1]? Regards, [1] https://www.opensc-project.org/opensc/wiki/SourceCode -- 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] Ownership issue and consequences on OpenSC project
Dear all, SM - I don't have any cards that can use this, others may. ePass2300 - GOOZE was willing to sending them out to developers, I don't know how many may have them, and if they do have they voted? It worked for me and I voted +1. (I think I voted.) We really welcome OpenSC contributors and offer free ePass2003. Any interested free software developer with some references (a participation in a FOAS project) may order a free ePass2003 from us: http://www.gooze.eu/feitian-epass-2003-free-software-developer-kit And gave away 70 at FOSDEM from memory. The ePass2003 also supports the SM branch from Viktor. So if you would like to do some development, I can only invite you to order a free ePass2003 from us. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Dear Douglas, What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! If we look at GIThub, there is a limited numbers of OpenSC forks, which means a relatively small workforce. Now, from a pure math, asking the workforce to compile and test other branches is quite a heavy job. One of the beauty of Free Software is also iterative modifications and evolutions. This only happens if the first version of a patch is committed fast and spreads using the Internet. So I would be more in favor of the proposal of Viktor (I guess?) to have all important patches go to staging rapidly. Then we compile and spread packages daily. Previously, we had only one unstable SVN version and it proved to be a big hunting place for bugs. To go further and have more people reviewing and testing, we may also have fixed-time releases, for example every 2 months. When we met at FOSDEM one year ago, Martin said he liked project with fixed-time releases. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit - howto?
Hello, Le 23 mars 2012 21:53, Magosányi, Árpád m4g...@gmail.com a écrit : I have registered to gerrit, because saying stuff is one thing, doing it is another. I guess I am supposed to verify and/or review. Which is what, and how? I have choosen Change I1e6f787d to experiment with, which is a nice oneliner. Some guy have changed an email address in a comment to his own. I believe reviewing means I should take a look at the patch to ensure that it is up to the standards. Well, I don't know the standards still, but as it is in the same form as the previous, I would think it is. so my verdict here is PASS. Also I believe verifying normally means testing the patch. But in this case maybe verifying the authenticity of the contact change would be the correct way. So I write an email to the old guy, and to the email address in the same source code which is from the same domain, and to some guy I guess is associated with the driver in question. If any one says yes and none says no, then I will push the verify button. Is it what someone supposed to do with this gerrit thingie? I think you are doing the good thing. Thanks. For the others, the patch Árpád refers to is discussed at https://www.opensc-project.org/codereview/#/c/252/ I encourage every user of the opensc-devel list to: - create a gerrit account - subscribe to the Email notifications. Go in Settings - Watched Projects and check the 3 notifications boxes for the OpenSC project - review patches and add comments I was not subscribed to the notifications at the beginning and then missed a lot of patch submissions. If you want to follow the OpenSC development is very important to subscribe to gerrit notifications (I think). Regards, -- 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] Ownership issue and consequences on OpenSC project
On 23/03/2012 19:10, Peter Stuge wrote: The problem is not that the code can not be reviewed, but that noone is doing review. Anyone can do it. I'd do reviews, but the last time I tried to really understand OpenSC's flow, all I got was an headache (a big one...) :( So it's not a will issue, it's more an understandig issue. At least for me. And I'd really like to be able to help, but it seems only a handful of people fully understand code flow... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/23/2012 11:10 PM, NdK wrote: I'd do reviews, but the last time I tried to really understand OpenSC's flow, all I got was an headache (a big one...) :( So it's not a will issue, it's more an understandig issue. At least for me. And I'd really like to be able to help, but it seems only a handful of people fully understand code flow... I neither understood a bit about it today morning. What I figured out is here: http://www.opensc-project.org/opensc/wiki/UseGerrit I suggest you to make a gerrit account, try it out, and update the wiki page with your findings. There are patches which easy to comprehend, there are errors which easy to spot, and I believe sometimes stating the fact that we lesser beings cannot correlate the comment with the code helps code quality. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] patch quality standards?
Looking at https://www.opensc-project.org/codereview/#/c/150/ , which is a patch which is overwritten by a later patch in gerrit, I started to wonder again about quality standards. And this: http://lwn.net/Articles/328438/ And there should be others. This is what I have gathered so far: - whitespace problems marked red in gerrit are bad - unchecked null pointers are bad - with a warning cleanup patch state the warnings which had been cleaned up - comment. the comment and the code should be in sync - provide a (description of purpose? man page?) with a command-line program and there is that fighter airplane book, but maybe it is too long and I am a big fan of unit tests if someone else have to do them ;) the same about programming contracts ;) I'm in no position to draw the rules, so I am not creating a wiki page out of this, but I suggest that someone do. It would help the work of code reviewers. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
