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
[opensc-devel] Automatic installation of MacOSX package for testing
Dear Friends, OpenSC-SM packages for MacOSX are now available from Viktor's branch: http://www.opensc-project.org/downloads/nightly/viktor/macosx/ Is there a way to install MacOSX packages automatically using command lines. This would allow to run simple testing. We've attached a Feitian R-301 and a Feitian PKI to the Mac OS X and would like to run test using Jenkins. As far as I understand, we can do: cd /tmp/ wget http://www.opensc-project.org/downloads/nightly/viktor/macosx/OpenSC-0.12.3-pre1-10.6.dmg hdiutil mount /tmp/OpenSC-0.12.3-pre1-10.6.dmg == Need to install here, but don't know how. hdiutil unmount /Volumes/OpenSC 0.12.3-pre1 Any idea how to install automatically: /Volumes/OpenSC\ 0.12.3-pre1\ for\ Mac\ OS\ X\ 10.6\ \(2012.03.26\)/ OpenSC-0.12.3-pre1-10.6.pkg 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] Automatic installation of MacOSX package for testing
Here it is, so no need to reply: cd /tmp/ wget http://www.opensc-project.org/downloads/nightly/viktor/macosx/OpenSC-0.12.3-pre1-10.6.dmg sudo hdiutil mount /tmp/OpenSC-0.12.3-pre1-10.6.dmg sudo installer -pkg /Volumes/OpenSC 0.12.3-pre1 for Mac OS X 10.6 (2012.03.26)/OpenSC-0.12.3-pre1-10.6.pkg -target / sudo hdiutil unmount /Volumes/OpenSC 0.12.3-pre1 for Mac OS X 10.6 (2012.03.26) 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
[opensc-devel] code review question
Would https://www.opensc-project.org/codereview/#/c/263/ also fall to the Commits that obviously should be bundled with some other change category? Half of the changes needed is at https://www.opensc-project.org/codereview/#/c/262/1, and the two or three lines being the main point has been changed between the two patches. And I am still confused by the place of gerrit in the development procedure. Maybe it is rtfm, then please point me to the fm. I see the patch in gerrit, its fate seems to be undecided for me, but the corresponding bug report is fixed as the patch got to staging. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] How the original patch submitter gets the review messages?
I have a little concern about the review procedure. If I go to the point in the code review comment, it will be short and not too encouraging. However the guys submitting the patches do the Right Thing, they are important ones, and some encouragement would be in place. Should I also include some thank you, and your patch is close to acceptable, just, or is it handled by other means? (maybe by some automated mailer enclosing the commit message, or some developer talking tu the submitter?) ___ 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] Why embedded SEs are more secure than smart cards
On Saturday, March 24 at 07:07AM, Anders Rundgren wrote: http://www.globalplatform.org/specifications/review/GPD_SE_Access_Control_v0_10_0.pdf By adding ACL information to keys during enrollment you can limit key misuse by bad apps. Although GP specifies a generic scheme not limited to SEs, the lack of developments by the vendors of connected SEs (Smart Cards), does in practice limit such features to embedded SEs like the one supplied for the Google Wallet. In SKS/KeyGen2 I have taken this concept one step further by allowing an issuer to specify that a PIN is only allowed through a GUI running in a TEE (Trusted Execution Environment). That is, if somebody spoofs a PIN dialog it won't give them SE access in the background. You know that a trusted execution environment is not necessarily secure, right? For example, Xen, VMware and various sandboxes have been broken in the past. Simply put, complexity is the worst enemy of security. The real problem, that your solution addresses is the following: Lack of a trusted user interface is a major shortcoming of todays 2-factor authentication. Schneier wrote a nice and short article about that in 2005 (http://www.schneier.com/essay-083.html). If the OS is broken nothing of this helps but that doesn't seem to be the case with mobile trojans. They are mainly just bad apps. Assumptions, assumptions. Also, when you say mainly it seems that you believe that there are at least some real problems... You're free to assume that your (or some) phone is secure. But I am not so optimistic. I think, secure enough is the better label for hand-picked use cases on the phone. Cheers, Frank. pgpWdxOcAnL0s.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
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] gerrit - howto?
Ludovic Rousseau wrote: I think you are doing the good thing. Thanks. I agree! I encourage every user of the opensc-devel list to: - create a gerrit account - subscribe to the Email notifications. Go in Settings - Watched Projects and check the 3 notifications boxes for the OpenSC project - review patches and add comments I second this! If you want to follow the OpenSC development is very important to subscribe to gerrit notifications (I think). I agree with this as well. It would of course be possible for gerrit to automatically send notifications for all new patches to the opensc-devel mailing list, we do this in several other projects, but it will of course result in more email traffic proportionate to the patches sent. Linux developers can handle it fine though.. //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/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
