Re: [opensc-devel] Why embedded SEs are more secure than smart cards
I see security as "journey" with no absolute end-destination. I'm sure that there will be screw-ups but it seems that iPhone and Android have fewer OS-level security breaches than Windows in spite of phones being "always connected". The #1 security issue appears to be how to give apps the "right" privileges and telling them to user in a meaningful way. I honestly do not have any "silver bullets" to that so I concentrate on OS-level security which AFAICT actually have solutions although software bugs and complexity (as you mention), indeed can destroy even the best of intents. From a more practical point-of-view I'm fairly sure that efforts integrating external smart card support like seek-for-android and GlobalPlatform's consumer-centric security tokens, will be about as "successful" as WSIM was some 10 years ago. At least if something like the OpenSC is supposed to power it. Google and Apple cannot deal with such a complexity. I don't see that there even *could* be a scalable QA process for the traditional driver-per-card model. At best there will be built-in support for PIV and CAC. The lack of provisioning standards is IMHO also contributing to the killing of external security elements as a viable security option for phones. I think that the smart card industry should begin to worry about SIM-cards. Virtualized SIMs may look quirky from a user-perspective but I believe there are ways to deal with multiple/changed devices that in the end will make this model *more* convenient. "Secure Credential Cloning" has already been performed by banks in Sweden for *millions* of consumers so it obviously works. The only problem that is unique for SIMs is "multiple use" but I guess this can be addressed at the network level, particularly for LTE and forward that are based on IP. Anders On 2012-03-26 23:34, Frank Morgner wrote: > 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. > > > > ___ > 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] patch base in gerrit
Le 27 mars 2012 10:50, "Magosányi, Árpád" a écrit : > Hi! > > We have the following symptoms: > - some modifications come as a set of patches. Gerrit lets you review a > patch a time. > - sometimes it is not even clear what are really the changes > - sometimes approved patches fail to apply > > It would be nice if > - all patches in gerrit would be shown as relative to a common base > - this base would be the currently approved head It should be the case. The problem is that we have a backlog of patches coming from github. And that are ordered. It is possible to resubmit them manually without the artificial dependency.It is time consuming but not really complex. > Another nice feature would be to automatically normalize submissions wrt > whitespaces. > It is a pity that patches should be rejected only because some misplaced > spaces, while there are tools out there to automatically reformat code. My solution is to configure VIM [1] to display extra spaces and tabs in red. http://www.carbon-project.org/Vim__How_to_prevent_trailing_whitespaces.html Bye [1] http://www.vim.org/ -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] patch base in gerrit
Hi! We have the following symptoms: - some modifications come as a set of patches. Gerrit lets you review a patch a time. - sometimes it is not even clear what are really the changes - sometimes approved patches fail to apply It would be nice if - all patches in gerrit would be shown as relative to a common base - this base would be the currently approved head Is there a way to achieve this? Another nice feature would be to automatically normalize submissions wrt whitespaces. It is a pity that patches should be rejected only because some misplaced spaces, while there are tools out there to automatically reformat code. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MacOSX installer issue
Le 27 mars 2012 10:14, Peter Stuge a écrit : > Ludovic Rousseau wrote: >> > Whenever I start pcscd manually: >> > sudo pcscd --foreground --debug >> >> Use: >> sudo /usr/sbin/pcscd --foreground --debug > > Is it re-executing? Suggest do like sshd and refuse to start without > full path in that case. By default pcscd starts in 64-bits mode. But the CCID driver provided by Apple is available in 32-bits only. So pcscd restart in 32-bits to be able to load the CCID driver. The situation will be simpler when: - all PC/SC drivers are Universal Binary with 32 and 64-bits support - or all 32-bits code has been removed from OS X. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MacOSX installer issue
Ludovic Rousseau wrote: > > Whenever I start pcscd manually: > > sudo pcscd --foreground --debug > > Use: > sudo /usr/sbin/pcscd --foreground --debug Is it re-executing? Suggest do like sshd and refuse to start without full path in that case. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit - howto?
Ludovic Rousseau wrote: > > automatically send notifications for all new patches to the > > opensc-devel mailing list, > > Peter, can you explain how to setup gerrit for that? I think only > Martin can do that change as the gerrit admin. It requires adding a patchset-created hook into the magic hooks directory in the gerrit install. The hook has to format and send the email to the list. It should send from an address which is subscribed to the list. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MacOSX installer issue
Le mardi 27 mars 2012 à 09:40 +0200, Ludovic Rousseau a écrit : > Use: > sudo /usr/sbin/pcscd --foreground --debug > > with the complete pcscd path. Or you get the error: > pcscd: posix_spawn: pcscd: No such file or directory Nice shot, you are right, this works now! Many thanks. -- 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
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] MacOSX installer issue
Le 27 mars 2012 09:19, Jean-Michel Pouré - GOOZE a écrit : > Dear all, > > I am building MacOSX packages for Viktor's Jenkins. Building packages > works. But after installing packages, OpenSC does not work. > > To reproduce the problem: > * Mac OS X 10.6 > * OpenSC packages from opensc-project.org > > I seems to be a problem with my MacOSX station, but I don't know which: > > Whenever I start pcscd manually: > sudo pcscd --foreground --debug Use: sudo /usr/sbin/pcscd --foreground --debug with the complete pcscd path. Or you get the error: pcscd: posix_spawn: pcscd: No such file or directory Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit - howto?
Le mardi 27 mars 2012 à 09:14 +0200, Ludovic Rousseau a écrit : > > Peter, can you explain how to setup gerrit for that? I think only > Martin can do that change as the gerrit admin. This has to change. We cannot have one admin on important software. On reason is that each of us can have an accident or become hill. Recently, Martin fell into cold water and got very cold. This is something that could happen to each of us, so it would be better to have several admins. Sharing resources is why we set up recently a buid farm with Viktor to be able to compile whatever happens. I can only encourage you to open the door of gerrit and jenkins to other members of the community, or we will one day or another set-up our own tools and share them. 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] MacOSX installer issue
Dear all, I am building MacOSX packages for Viktor's Jenkins. Building packages works. But after installing packages, OpenSC does not work. To reproduce the problem: * Mac OS X 10.6 * OpenSC packages from opensc-project.org I seems to be a problem with my MacOSX station, but I don't know which: Whenever I start pcscd manually: sudo pcscd --foreground --debug Password: /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/debuglog.c:240:DebugLogSetLevel() debug level=debug /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/pcscdaemon.c:585:main() pcsc-lite 1.4.0 daemon ready. /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/readerfactory.c:1545:ReaderCheckArchitecture() Send respawn signal to pcscd (pid=151) /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/pcscdaemon.c:678:signal_respawn() Got signal to respawn in 32 bit mode /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/pcscdaemon.c:294:SVCServiceRunLoop() Preparing to exit... /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/readerfactory.c:1048:RFCleanupReaders() entering cleaning function pcscd: posix_spawn: pcscd: No such file or directory /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/pcscdaemon.c:611:at_exit() cleaning /var/run /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/pcscdaemon.c:625:clean_temp_files() Cannot unlink /var/run/pcscd.comm: No such file or directory /SourceCache/SmartCardServices/SmartCardServices-36160/src/PCSC/pcscdaemon.c:631:clean_temp_files() Cannot unlink /var/run/pcscd: No such file or directory I wonder if something is not going wrong on my Mac OS X station. Any idea? I know this is very little debugging, any help appreciated. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit - howto?
Le 27 mars 2012 07:01, Peter Stuge a écrit : > Ludovic Rousseau wrote: >> 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.. I agree with Peter. New patches sent to gerrit should be sent to opensc-devel list. We do not (yet) have so many patches. And this should remind people that a new patch has to be reviewed. Peter, can you explain how to setup gerrit for that? I think only Martin can do that change as the gerrit admin. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
"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] How the original patch submitter gets the review messages?
Hello, Le 26 mars 2012 18:01, "Magosányi, Árpád" a écrit : > 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?) I don't think that people sending pull requests on github will get emails from gerrit. So comments adding on gerrit will not (I think) be sent to the patch author. Maybe gerrit should be the only entry point for patches. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] code review question
Le 26 mars 2012 17:27, "Magosányi, Árpád" a écrit : > 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 https://www.opensc-project.org/codereview/#/c/263/ is incomplete/bogus. Very good job at reviewing the patch. Thanks. > 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. The changes have been merged (by me) on github but not yet on gerrit. The 2 repositories (github and gerrit) have diverged and it is problematic. I think Martin is working on a merge of the 2 repositories. But I don't know what to do if a patch is accepted on github and then rejected on gerrit. Gerrit should be the only entry for patches to avoid such problems. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
