Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Le mardi 27 mars 2012 à 03:19 +0200, Peter Stuge a écrit : There was always a way for the ccid package to work around the problem, I don't know why this wasn't done, but I guess that it would have required too much effort, and noone contributed such effort to the ccid project. I guess that a perfect patch for ccid would have been most welcome. I agree there is a lot of work around libusb. But ... In bazar development, we should agree to release unperfect code in one unstable branch and let the community fix it. One reason is the limited time of reviewers. You write we will not work for you. We noticed, thanks and this is NOT a problem. This is where the process should evolve to take the notion of limited resources into account and give the community at large more power and freedom. I am worried that OpenSC GIT development is too scattered. It looks like: Scooby-Doo, Where Are You! In Scooby-Doo, whenever there is a challenge, the team decides to split and look for the monster. Then when a monster shows up, the character is alone to fix it and receives no help. In other words: too many branches = No review = No testing from end-users = no contribution = nothing. Notice this is what happened to tokend, so we should worry. Unless patches are committed to GIT unstable branch very quickly, let's say in days, there will be no testing/review of patches. So I would be in favor of letting main developers commit their changes to ONE SINGLE git staging branch directly and let developers/users fix the code. Anyway, let's give some time to Gerrit to see if we are still in the Scooby-Doo, Where Are You! situation. If this does not work, let's get back to one single unstable branch to be united again. 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
Magosányi, Árpád wrote: Graeme did some rework of the patch, but generally did not seem to agree with the review. The new solution included the addition of new API calls, however without any documentation. As anyone who has looked at the code and doxygen output, libusb is quite well documented, so the lack of documentation was obviously a problem. We are talking about lack of some documentation vs. a serious useability issue. As I explained, it was not and is actually still not evident in the libusb community that the bug was particularly serious (ie. that it was happening very often and/or for very many) since there was neither much activity following up on the original report, nor in the ticket. There has been significantly more activity for many other things. The way to address this is obviously not to shoot the people engaged in such other activity, but to make sure that your important message is heard loud and clear, when you have one. There have even been commercial inquiries for libusb-related projects, but none for this ticket. I am not saying that commercial inquiries drive my work on libusb, but they do indicate what matters to some others. Have you noticed it yet? I'm not sure what you mean? I personally have not experienced the bug. Yes, I use ccid, although only occasionally. Open source only works if you take responsibility for every single line of code that you are using. Open source only works if you understand both the technical and management issues. I am talking about what users have to do to make open source work for them. You seem to talk about how you wish projects to do management? This list is not about libusb development and I only tried to reply to the direct question about peer review for one particular libusb bug. Obviously there is much more detail to the libusb story than I can possibly write in a way relevant for OpenSC. I'm happy to discuss further in another more fitting media. #libusb on IRC or direct email or libusb list seem good candidates. The operational words being working and small here. I would very much appreciate if you study the work that has been done on libusb by me and other contributors in the last three years or so, before starting to talk nonsense about small work units. Unless you invest this time for thorough research I'm afraid you aren't in a position to make any remarks on the topic. I'm sorry if that sounds harsh, but if you've done the research I am convinced that you will see my point, and I will be more than happy to continue discussing off this list. It can be argued that a feature and its documentation are two different work units. No, not really, not for a library where documentation is otherwise quite complete. You will find out that leading a succesfull open source project have much more to do with effectively motivate people to do the work than being a good programmer, and sometimes aiming for the perfect code is the slowest way to get good code. I don't know about you, but I'm not at all interested in success if it means having to settle for mediocracy in software. Success means nothing if the software we output is anything less than the best we can do if we really apply ourselves. //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
Peter Stuge wrote: So I would be in favor of letting main developers commit their changes to ONE SINGLE git staging branch directly and let developers/users fix the code. It's an interesting idea, but it places a significantly higher workload on the developers if there is more than one active at any given time, since instead of each person having to juggle only their own changes, everyone has to juggle everyone's changes. To clarify, the more traditional approach is to have repositories or branches for each developer in one central project location, even if these repos/branches have different topics. //Peter pgpX6ZQCe2MtD.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] Ownership issue and consequences on OpenSC project
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. Maybe its an stupid idea (or already done), but can't we virtualize (and use it in Jenkins) smartcards? ___ 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 2012-03-26 09:17, helpcrypto helpcrypto 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. Maybe its an stupid idea (or already done), but can't we virtualize (and use it in Jenkins) smartcards? The stupid part of this, is that it should rather have been the card vendors that verified their products' compliance against a well-defined middleware stack. The current system is a *disaster* except for those who make a living writing (or supporting) SC middleware. Embedded SEs will work out-of-the-box. ___ 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] Ownership issue and consequences on OpenSC???project
On Monday, March 26 at 09:17AM, helpcrypto helpcrypto 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. Maybe its an stupid idea (or already done), but can't we virtualize (and use it in Jenkins) smartcards? This has been done before, for example, look at http://vsmartcard.sourceforge.net/ which provides a nice PC/SC interface to the virtualized card. However, there are a lot of smart cards out there and you would have to implement a state machine (and other characteristica) for each of them. Virtualizing smart cards would be much simpler if the smart card OS was available. Then all you would have to virtualize was I/O... Cheers, Frank. pgpashdjqg4Wf.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] Ownership issue and consequences on OpenSC project
Dear Peter, http://en.wikipedia.org/wiki/Peer_review which I guess you may already be familiar with. Yes, I have heard about peer review. Just remember there was a peer discussing about a 60 second timeout bug in libusb/pcscd. The first peer says the bug is in libusb. The second peer says the bug is in libccid. And the bug never gets fixed. And ALL tokens may suffer from this 60 seconds timeout. Peter, as you are a peer of libusb, maybe you could comment on the 60 seconds bug and explain why it was known and unfixed for more than a year. Really this would help understanding the concept of peer review. I am not against the concept itself, just I don't know how to arbitrate between 2 peers and handle a project of 100.000 users with only 2 peers. This is mostly what happened to OpenSC lately: bugs and fixes were know BUT 1) not applied 2) not tested in beta by a large number of users. This goes diametrically against the goal of software quality. If you look at the number of GIT forks in GITHUBS, there is only a limited number of peers with limited time. I would say around 10 developers. Clearly a lack of workforce, so we need the help of a broader community. In a large community of users (10.000), leveraging on Internet, you can help you find and chasse a lot more bugs. So to me the bazar model will always be superior to the cathedral model. Read Raymond essay, this is clearly the model here. Let us give time to see how the new architecture based on Gerrit and a packaging farm works. Time will tell if this is efficient. We'll see how fast OpenSC could go forward. IMHO, it could go very fast. Here what we are talking about is efficiency, not concepts. 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
Jean-Michel Pouré - GOOZE wrote: Just remember there was a peer discussing about a 60 second timeout bug in libusb/pcscd. The first peer says the bug is in libusb. The second peer says the bug is in libccid. And the bug never gets fixed. And ALL tokens may suffer from this 60 seconds timeout. Peter, as you are a peer of libusb, maybe you could comment on the 60 seconds bug and explain why it was known and unfixed for more than a year. As far as I know this bug was first brought to the attention of the libusb community unrelated to anything libccid or pcscd, in an email from Graeme Gill, who also suggested a solution. In his first reply the maintainer (Daniel Drake) confirmed the problem, and raised several important points after reviewing Graeme's suggested solution. Graeme did some rework of the patch, but generally did not seem to agree with the review. The new solution included the addition of new API calls, however without any documentation. As anyone who has looked at the code and doxygen output, libusb is quite well documented, so the lack of documentation was obviously a problem. In one sense Graeme had fixed the bug already, in another sense he left it up to members of the libusb community to pick up the problem description and the suggested solution, and resolve the problem on their own. Daniel's reply came less than 48 hours after Graeme's report. Five months later, the ccid maintainer created http://libusb.org/ticket/56 including a forward-ported version of the revised suggested solution, still without documentation. Daniel's involvement in the project was slowing down, he had made me co-maintainer, and I was busy being overwhelmed by quite many and quite difficult practical details of adding Windows support. There was no further significant feedback on the ticket until one more tester confirmed it working. I did a round of review and provided feedback on what I found important. Two months later you commented in favor of including the patch. There still didn't exist any documentation, and noone had taken any action based on my review. Several months later, Hans de Goede being paid by Red Hat partially to work on libusb stepped up and not only brainstormed a resolution for my concerns, but he also created documentation for the new APIs. Given this, the fix was included in libusb.git master. In the time between each of the above events everyone involved was obviously also working intensely on many other matters, possibly perceived as being more important, possibly because of the lack of feedback in the ticket, or because of lack of further reports of the same problem on the mailing list. On behalf of the libusb project I would like to express a sincere thank you to you, for testing and commenting in support of the patch! At the same time I expect you to understand that unless you or someone else produces a perfect patch according to peer review standards then you must accept that others will work for you in their own time exclusively when they choose to do so. This is a very important aspect to understand about open source software. Open source only works if you take responsibility for every single line of code that you are using. Really this would help understanding the concept of peer review. I hope my recount helps. Feel free to ask further! (As it happens, everything I wrote above is clearly visible either directly in the libusb ticket which you commented on, or in emails linked to from comments in the ticket preceding yours.) I don't believe that anyone in the libusb community has ever suggested that the problem would be in the ccid package. I don't know who you quoted above. There was always a way for the ccid package to work around the problem, I don't know why this wasn't done, but I guess that it would have required too much effort, and noone contributed such effort to the ccid project. I guess that a perfect patch for ccid would have been most welcome. I am not against the concept itself, just I don't know how to arbitrate between 2 peers and handle a project of 100.000 users with only 2 peers. This is mostly what happened to OpenSC lately: bugs and fixes were know BUT 1) not applied 2) not tested in beta by a large number of users. I hope you realize that 2 drives 1, not the other way around. we need the help of a broader community. Don't hold your breath. Noone will work for you. If you want something you have to do the work. And more importantly you have to do the work exactly the way your reviewers want it. In a large community of users (10.000), leveraging on Internet, you can help you find and chasse a lot more bugs. You seem to be in favor of pushing code to users without developers first making every last effort to discover and fix all problems. I think that development model is reckless, irresponsible, and an insult to users, other programmers, and software in general. Open source not having deadlines and thus not requiring
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 03/27/2012 03:19 AM, Peter Stuge wrote: Graeme did some rework of the patch, but generally did not seem to agree with the review. The new solution included the addition of new API calls, however without any documentation. As anyone who has looked at the code and doxygen output, libusb is quite well documented, so the lack of documentation was obviously a problem. We are talking about lack of some documentation vs. a serious useability issue. Have you noticed it yet? OpenSSL comes to mind. I am not saying it is perfect, but definitely better than known buggy code. It is the most widely used crypto library despite the fact that its documentation is seriously lacking. Another story is the early days of linux. You might remember: there was the code, and not much documentation, and we were so happy with it. And some guys stepped up and started writing documentation like hell. To reach that point, they needed two things: - functionality to document - functionality they are happy with enough to lend a hand by documenting it At the same time I expect you to understand that unless you or someone else produces a perfect patch according to peer review standards then you must accept that others will work for you in their own time exclusively when they choose to do so. This is a very important aspect to understand about open source software. Open source only works if you take responsibility for every single line of code that you are using. Open source only works if you understand both the technical and management issues. One question in any project is the what is the optimal size of a work unit?. While it is certainly not a question which can be exactly answered, it can be argued that: - it is not good to have work units which do not transform working code from working code - the smaller the work unit size, the better for the one doing it The operational words being working and small here. small is especially important for any crowdsourced effort, because the lower the entry threshold, the more the number of participants. And this is not linear but exponential. It can be argued that a feature and its documentation are two different work units. I recently saw a nice quote from Linus: I'm a big believer in technology over politics. ..in response to a question about Linux patches from Microsoft. Article: http://www.linux-mag.com/id/7439/ I agree with him. It's difficult to argue with perfect patches. However, when patches are anything less than perfect, as they often are, then the responsibility to perfect them lies with the contributor. While a project manager certainly have the authority to decide on what should be accepted, I would strongly suggest you to research the context of this Linus quote a bit more, and read through Cathedral and Bazaar once more a bit more thoroughly. You will find out that leading a succesfull open source project have much more to do with effectively motivate people to do the work than being a good programmer, and sometimes aiming for the perfect code is the slowest way to get good code. ___ 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
Jean-Michel Pouré - GOOZE wrote: iterative modifications and evolutions. This only happens if the first version of a patch is committed fast and spreads using the Internet. WTF? This goes diametrically against the goal of software quality. It is becoming clear to me that you have absolutely no interest in increasing or even maintaining quality, rather it seems that you consider the fastest code change possible to be the only worthwhile goal. This may be the case if all programmers are code monkeys, because they will be unable to ever produce anything of quality anyway. In open source projects code monkeys generally learn to become better programmers thanks to peer review. http://en.wikipedia.org/wiki/Peer_review which I guess you may already be familiar with. //Peter pgpM9RULCSG5q.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] Ownership issue and consequences on OpenSC project
On 03/25/2012 01:14 PM, Peter Stuge wrote: Jean-Michel Pouré - GOOZE wrote: iterative modifications and evolutions. This only happens if the first version of a patch is committed fast and spreads using the Internet. WTF? This goes diametrically against the goal of software quality. Please calm down. Software quality is a complex issue, and sometimes does not work the way one would intuitively think. A good example is this false assumption you were building on. History has shown that the bazaar model is capable to provide quality software, and in a quite wide range of settings it is even more capable than cathedral. We also seen examples of very capable programmers unable to keep up with the bugs in their code, because lack of resources. Think about Hurd for a while. Bazaar shown to be more effective in code quality for a number of reasons: - it is more capable to bring in resources. programmers, reviewers, testers - its turn-around time is much faster; the same patch might get written in a faulty way, tested, fixed and enhanced in the same time while in cathedraal it gots written right at the first shot (but still not enhanced) http://www.catb.org/~esr/writings/homesteading/cathedral-bazaar/ with which I guess you are already familiar with. Moreover: code quality is traditionally defined in a non-functional way. However (at least to me) code quality also have a functional ingredient: how the code functionality fits the users' needs and expectations. We have plenty of proofs that bazaar just cannot be beaten on this one. For an example compare the Linux and FreeBSD user base (though I guess even the FreeBSD project does not count as a cathedral anymore). ___ 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] 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] 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] 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] 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] 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
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] 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] 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
