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
Many thanks for coming back on topic for OpenSC! :) Jean-Michel Pouré - GOOZE wrote: > In bazar development, we should agree to release unperfect code in > one "unstable" branch and let the community fix it. I don't oppose having stable and unstable development processes per se. But usually it's not so meaningful for the smaller projects. > 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. Well, it is a problem if you (I don't mean you personally or your company, I mean everyone other than active developers) want a change in the code. There are of course many ways to encourage someone else to help, ranging from simply asking nicely to some form of payment. > 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. The alternative, which is *always* available, and which comes with no risk for any party, is for those with interest in some changes to the code to generate it themselves. Of course, in order to avoid risk, it is important to work closely with the project community, so that there is no duplicated effort and so that the final result can be commited quickly. > I am worried that OpenSC GIT development is too scattered. It looks > like: Scooby-Doo, Where Are You! Nice reference hehe! :) Distributed development is IMO a feature, not a bug. As long as all parties consciously work together, having many git repositories and branches is not a problem at all. Linux is the textbook example and since they have very high standards for commits it is even easy for users to take advantage of the quite powerful features in git and combine multiple different branches into one. It's actually quite impressive how well this works with the Linux kernel. > 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. Fortunately two git branches are only a command away, so when we find monsters we could quickly gather the entire gang and fight the monster together if this is what we want. > In other words: too many branches => No review Why, specifically? I can only think of a few reasons: * Because reviewers are overwhelmed by the number of changes to review. This would be no better if all changes were happening in one and the same place. Probably it would be worse, since all changes were mixed together, making targeted testing of specific features more messy. * Because reviewers can not find the changes to review. This can easily be remedied by gathering all repositories and branches in a single location, which is something I believe strongly in. Why does fewer branches mean more review? I would instead argue that lack of individual commit quality is what stifles review. The better a patch is the easier it is to review. For reviewers it starts with the commit message. The way to make a commit really easy to review is to write a commit message which educates the reviewers about the change, including some background for the relevant code and the process for making the decisions made during the change. The education is especially important if there aren't many other developers familiar with the code. Writing good commit messages and in particular writing education material requires a quite different skillset than writing code. This problem is inherent with peer review if peers are distributed in location and experience, like on the internet. > Unless patches are committed to GIT unstable branch very quickly, > let's say in days, there will be no testing/review of patches. Huh? Review happens before commits enter the staging branch, not the other way around. > 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. > Anyway, let's give some time to Gerrit to see if we are still in > the "Scooby-Doo, Where Are You!" situation. The key really is review, not testing. If you can help with review (or influence someone else to do so) that is incredibly valuable for any project! > If this does not work, Let's see if we get there. Thanks! //Peter pgpbrXjOHKO6s.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
"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
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
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: > 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 t
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
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
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
> 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 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
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/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
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
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
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
On 3/23/2012 3:29 PM, Martin Paljak wrote: On Fri, Mar 23, 2012 at 22:16, Douglas E. Engert 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 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
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 Fri, Mar 23, 2012 at 22:16, Douglas E. Engert 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 3/23/2012 11:48 AM, Martin Paljak wrote: > Hello, > > On Fri, Mar 23, 2012 at 15:17, "Magosányi, Árpád" 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 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 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
"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
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
Hello, On Fri, Mar 23, 2012 at 15:17, "Magosányi, Árpád" 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
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
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