Re: [opensc-devel] Status of the server migration
Ludovic Rousseau wrote: * Trac/Wiki/ - any progress here? I remember so offerings and questions to migrate, but no status update since - maybe I missed it? We are waiting solution from Peter. I don't think we can count on Peter. I had a bad experience on the libusb project and waited after Peter for a new release during 2 years before participating to a forked project (libusbx). You waited and you complained. I wish you would have actually produced a release branch instead, even if that branch included nothing at all besides the #69 bugfix which bit ccid. My guess is that noone would have bothered with a fork if you had done that. As I have explained several times in places where you have probably already seen it, if someone had proposed a 1.0.8.1 branch with only bugfixes then I would have been happy to release it. The idea to do that myself never occured to me, and while the very loud project leader of the fork loves to spin rhetoric in an attempt make more out of that than there really is, the fact remains that nobody came up with a bugfix release branch. It's really easy to wait and to complain. It's apparently really hard to produce something that can be released. I do not like it at all but we may have lose all the bugs I think that's silly. Andreas, can you wait until mid-January before retiring the server so I have a chance to backup what I can? I am not at home now. sarcasm I don't think we can count on you to make a backup within that time. /sarcasm I hope you agree that my above sarcasm is absolutely ridiculous.. Andreas Jellinghaus wrote: Sure, that is fine. I'd prefer to shutdown those parts that are migrated already - i.e., make the SVN read-only (is this possible), set the mailing lists to moderated etc. Feel free to shut everything down besides SSH access. If someone sends me an index.html file explaining that Trac is down because of the migration then I'm happy to host it on the same URL that will later serve the Trac instance. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of the server migration
Andreas Jellinghaus wrote: * Trac/Wiki/ - any progress here? I remember so offerings and questions to migrate, but no status update since - maybe I missed it? No progress, the offer is still good, but no chance of making it happen before end of year. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Ludovic Rousseau wrote: Merging a pull request from github adds a merge pull request commit. The history is then not very nice (linear) but I don't know a better way using the github web interface. It isn't neccessary to use the github web interface just because github is used to host the repository. It works just as well to pull from any remotes and create fast-forward merges. But of course that will then work around the pull request workflow that github enforces. Greg Troxel wrote: You should rebase your patches above OpenSC/OpenSC master. Ok, but pardon my git ignorance: I thought that one should never rebase a tree that will be published and pulled from? Or only if it's published and someone tries to *base a new tree* off of it? This is somewhat controversial, but from my experience in both open source and large private projects, the key issue is not to rebase branches that other people have made commits on top of, or merged into other branches. I disagree that rebasing is controversial. This is just a tool. Rewriting history is never a problem, as long as everyone who is working together wants to understand how repositories work and how easy it is to resync with rewritten branches. Given a local branch foobar that tracks contributor/master here's what to do when the contributor has rewritten her master: git checkout -b orig_contrib_master contributor/master \ git fetch contributor \ git rebase --onto contributor/master orig_contrib_master foobar Clean up after the rebase is done: git branch -D orig_contrib_master Since rebase of the local branch is required, of course it is important that the mechanics of rebase are well understood. I find that it's helpful to rebase branches proposed for merging. There are arguments both ways. I like the look of linear history. On the other hand, depending on the development model, merges may be a more accurate representation of the code history. Viktor Tarasov wrote: I also vote for rebase of the feature branch before merging it to the master branch. Note that any testing and review of the branch should happen *after* that rebase, to avoid a lot of wasted effort. If this procedure seems annoying, then use cherry-pick, especially when it's going about the minor changes. cherry-pick is almost the only thing that rebase does. It's often easier to just use interactive rebase to do the picking. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pam_pkcs11 with many certificates on a single token
frederic.comb...@cea.fr wrote: Here is my patch (actually, 2 patches that depend if the patch concerns only the error 2328 (patch 1) or the whole block processing the return value of verify_certificate() (patch 2)). Patch 1 is obviously incorrect because your change is inside a conditional. Patch 2 is the correct change in code flow, but please do not ever use comments to remove source code. The version control system keeps track of history, and commented out code is very confusing, not to mention ugly. It would be great if you sent the change in an easy format. Ludovic mentioned pull requests. You'll need to know git and github specifics to do that. If you don't, maybe someone can generate a commit in your name. Thanks //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC with VMWare View
Michael Wisniewski wrote: Could not open module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so: /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so: cannot open shared object file: No such file or directory I was wondering if you knew which package I would have to install to obtain libopensc-pkcs11.so.so. That filename is a programming error in the application that tries to open it. I guess that's closed source, so all you can do is make a symlink pointing at opensc-pkcs11.so. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Ludovic Rousseau wrote: The idea of git is to _not_ have to give access. Just send pull requests and I (or another admin) will pull your code. Yes and no. Multiple people writing to a central repo works perfectly fine also with git. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Ludovic Rousseau wrote: Andreas, the host available at opensc-project.org will disapear at the end of the year 2012 [2]. I think you misunderstood what Andreas wrote in his email. I think that what Andreas was saying is that someone else needs to be root and care for the machine. I don't expect that it will be any problem whatsoever to keep the VM around until whenever it is easy to change DNS, as long as someone is actually taking care of the system. Of course when noone is able to and other offers aren't useful, then all that remains is to rely on free (beer) services like github or SF. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Viktor Tarasov wrote: I propose to start migration the week 19-25.11 . I'll have more free time: - sources: all sources will migrate to github; - CI: CI server is currently hosted by 'opensc.fr' ; - download: on the same platform can be hosted the file server; - TRAC (wiki?): it seems that Peter Stuge proposed to do something with Trac. Peter, if you are here, can you take this part, or at least explain how it could be done, please? If no suggestions, Trac can also be hosted by 'opensc.fr' . Educating someone on how to do a migration is as I'm sure you know a whole lot more work than performing the migration. If there's desire I'm of course still happy to host a Trac, but please keep in mind that Trac is a lot less useful when source code is somewhere else. Please add my SSH key on the server and let me know, if you want me to look into moving Trac out. - mailling list: the same, if no other suggestions, I'm ready to install/migrate it to 'opensc.fr' platform. Would be nice if one of the experts explain what is the actions to follow for such migration. I don't like mailman too much. I've set it up, but I don't use it. I'd suggest using SF for the list(s?). //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Andreas Jellinghaus wrote: I wonder what we can or should do to improve the state of the project. I think it's clear that only very few entities are putting resources into the project. there hasn't been any real discussion, no back and forth about the merrits of the different proposals, and no convergence on one option or decission by anyone. I think even this is way too much to expect from those who do put resources into the project. Noone who is contributing seems to have much experience from hosting, so discussion about hosting is really difficult. (I may have plenty of experience, but I don't contribute very much to the project.) It seems to me the state of the project is defunct: while there are requests, proposals, options and offerings, we are not getting towards a decission or action it seems, as noone decides anything or gets people to agree or to do things. There's a fairly fundamental disagreement between development styles. I e.g. advocate security-conscious development and great results, even if slow, while everyone else who has spoken on that matter advocates fast change with perhaps less importance on technical quality and elegance. It's sad that less-than-great results is acceptable in open source under any circumstance, but since I'm not even putting development resources into the project it doesn't matter at all what I think about that. IMO it's largely a waste of time to migrate away from an existing working system unless the services really can not be updated in place. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Viktor Tarasov wrote: - mailling list: the same, if no other suggestions, I'm ready to install/migrate it to 'opensc.fr' platform. Would be nice if one of the experts explain what is the actions to follow for such migration. I don't like mailman too much. I've set it up, but I don't use it. I'd suggest using SF for the list(s?). Could you expand 'SF' or give the link, please? Sorry - missed this one. SF = sourceforge While I disagree with most other uses of SF because of their quite unfriendly terms of service (a function of US law of course) I think that mailing lists are OK. Subscribing to lists doesn't require an SF account, and SF doesn't add overly much spam to the posts. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
Anders Rundgren wrote: http://www.theregister.co.uk/2012/11/13/trustzone_company Smart cards? Don't think so. TrustZone isn't half bad hardware. But I bet that the solution they come up with will still use exactly the same old APDUs, with just a minimum bolted-on, in order to make something that just barely works. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Donation of a dedicated server to the OpenSC community
Andreas Jellinghaus wrote: if there is noone specialised on setting up such a server and keeping it running well and secure There is, and my offer still stands. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Need help building Mac OS X packages
Jean-Michel Pouré - GOOZE wrote: Can you help? Difficult without actual error output. The mail only included the executed commands. //Peter pgpyInSbTHDae.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] PIV-tool in windows environment
Ravneet Singh Khalsa wrote: Is there equivalent command for Windows specific environment ? The command seems to be pointing to engine_pkcs11.so and opensc-pkcs11.so files. I couldn't find these files anywhere. .. I am a programmer and I understand only programming languages. It's good for programmers to know about systems too. Look for the same files named .dll. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SIGV when deleting certificate but not related public key
Andreas Schwier wrote: I will first need to write a small test in C to reproduce the problem. Right now we test from Java, which makes debugging a real nightmare. Maybe you can reproduce it using some of the existing command line tools? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
NdK wrote: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf http://youtu.be/gv3dxjvqk7Y //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
NdK wrote: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf Tks. That's the (or one of) article I remembered but couldn't find... http://google.com/search?q=chip+and+pin+broken ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Jean-Michel Pouré - GOOZE wrote: I was quite busy and failed to do any work these last days. Remember how much easier it is to write email with opinion. //Peter pgpNhpOSPqCvo.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] new server hoster and adminstrator for opensc-project.org required
Andreas Jellinghaus wrote: A small follow up: As far as I know the server does: * svn server / code repository * svn server / release tar.gz repository (also containing binaries) * build robot to create nightly builds and or automated builds (jenkins?) * many trac repositories - wiki, browser for svn, bug tracking (the bugs are not very helpful if noone works on them) * mailing lists So I don't know if all svn code repositories have been migrated to githup etc. I have little knowledge what plattform would be best to fill the gaps so that we can shut down the server. If source code repos haven't been converted to git I suggest to do so right away. Release tarballs can and should be hosted separately from source repos. I suggest that they are only ever uploaded manually. (Makefile) A build robot can and should be hosted separately from source repos. Trac integrates with git, it's not stellar in any way, but it works. Modern Trac versions support multiple repos. I would suggest to merge the different Trac instances into a single one. This will take manual labor, messing around with the Trac databases. Mailing lists aren't very fun to self-host IMO, but can certainly be done. I run integrated Trac and git hosting for several projects for years, I'm happy to do so also for the opensc projects, in particular the small ones. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Supporting card Handelsbanken (SHB) BankID
Peter Åstrand wrote: proprietary BankID application I suggest to try https://fribid.se/ out. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
Martin Paljak wrote: IIRC it was apple who wants to make a phone self-register. Meaning there are no parts to add or remove from the phone and you pair it to your operator online. The question IMHO is how much do telcos want to give up the freedom of controlling access to their networks... Prepaid SIMs in the US are locked to the phone they ship with, upon activation in the store. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial support for SmartCard-HSM
Andreas Schwier (ML) wrote: we've put in a pull request in github/opensc/staging to include a card driver and PKCS#15 emulation module for our SmartCard-HSM [1]. That sounds nice. I haven't yet looked at the code. This driver is a read-only driver that works with SmartCard-HSMs that already contain keys and certificates. Is there a technical reason for the driver to be read-only? I mean, it would be nice if OpenSC could also be used to initialize tokens. Perhaps write support would be optional at build time. Kind regards //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Viktor Tarasov wrote: I would like to start preparation of the new release based on the 'staging' branch of GitHub OpenSC . Your suggestions proposals are heartily welcome. I suggest, as always, to not release anything without good review. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
Ludovic Rousseau wrote: I don't know where the Gerrit's review directory is and could not find a gerrit config file. ps www $(pidof java) $ pidof java 24079 $ ps www $(pidof java) PID TTY STAT TIME COMMAND 24079 pts/2Sl+ 29:22 java -jar jenkins.war --httpPort=8889 --httpListenAddress=127.0.0.1 --ajp13Port=-1 --prefix=/autobuild There is another java process Good find! $ ps www 25775 PID TTY STAT TIME COMMAND 25775 ?Sl 681:58 GerritCodeReview -jar /home/git/codereview/bin/gerrit.war daemon -d /home/git/codereview --run-id=1338275543.25754 Then /home/git/codereview is gerrit's directory. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
Ludovic Rousseau wrote: I don't know where the Gerrit's review directory is and could not find a gerrit config file. ps www $(pidof java) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
Jean-Michel Pouré - GOOZE wrote: do you confirm that anyone can now make a pull request using only GIThub? As you know I for one am strongly against centering anything around the github workflow, especially when gerrit is available. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
Jean-Michel Pouré - GOOZE wrote: * Do we still fetch opensc-project development hooks? scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ s I don't know what it is for and propose to remove it. Do you agree that it's difficult to propose to remove something you don't know what it is for? :) The hook creates the Change-Id for gerrit, allowing a logical change to be tracked across multiple iterations of the actual commit e.g. in response to review. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Announcing debugging server and asking for advice
Jean-Michel Pouré - GOOZE wrote: * If possible, I would like to restrict the number of concurrent sessions in OpenSSH an set it to one. There should be no idle session. If someone is already connected doing debugging, OpenSSH should reject connection. This is the most tricky part of the settings as I have NO IDEA how to achieve this. You can modify sshd a little or use some PAM module which I'm sure can implement this policy. For sshd you can start by setting MaxSessions to 1, but there's no MaxAuthenticatedSessions setting. Be careful with MaxStartups, or it becomes very easy to deny service. //Peter pgp61BsKzbAG3.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] Announcing debugging server and asking for advice
Jean-Michel Pouré - GOOZE wrote: You can modify sshd a little or use some PAM module which I'm sure can implement this policy. For sshd you can start by setting MaxSessions to 1, but there's no MaxAuthenticatedSessions setting. Be careful with MaxStartups, or it becomes very easy to deny service. Thanks, I will try this way. Note that MaxSessions doesn't do what you want, so if you don't want to get into the sshd code then you have to configure some PAM thing. Doing it in sshd will probably be faster though. //Peter pgpgTrzvg0Fv2.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] PKCS15init profile to omit a part of path
Martin Paljak wrote: Maybe it would be better to have a single sticky pkcs15-ish mapping for a fixed profile card in a single location (like the pkcs15 emulation drivers) and allow pkcs15-tool (which does not try to create any PKCS#15 structures) to re-generate exposed key slots and replace exposed certificate slots. And extend that API as needed. Yes, absolutely. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Nguyễn Hồng Quân wrote: I'm starting from the current codebase, which uses a emulation layer, so I don't know other choice than continue with this approach. First create the improved infrastructure in OpenSC that your work needs. Maybe it would be better to have a single sticky pkcs15-ish mapping for a fixed profile card in a single location (like the pkcs15 emulation drivers) and allow pkcs15-tool (which does not try to create any PKCS#15 structures) to re-generate exposed key slots and replace exposed certificate slots. And extend that API as needed. I don't really understand this idea. - Now, to solve the problem of the path I mentioned at the beginning of this mail thread, I change a bit in gpg_select_file, to automatically ignore the part of DF PKCS15-AppDF (5015). Does it resemble the idea sticky pkcs15-ish mapping for a fixed profile card? Yes and no. The point is that mapping between card layout and p15 will happen only in a single place. - What re-generate exposed key slots and replace exposed certificate slots is for? Code working with keys and certificates should never work with p15 operations for modifying structure, but be restricted to the structure exposed by the p15 mapping. Modifying that (virtual) p15 structure would use another API. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Ludovic Rousseau wrote: 2012/5/27 Jean-Michel Pouré - GOOZE jmpo...@gooze.eu: Sufficient privileges in GIThub should be granted to a group of people. Trust is enough to agree on commits. FOAS means Free and Open. FOAS = ? I guess FOSS. The open does however not mean that the entire world must have write access, it's about read access. Trust is enough to agree on commits. makes no sense whatsoever to me. The closest that makes sense to me would be: Trust comes from agreeing on commits. Of course everyone has different priorities. It makes me sad that quality isn't the top priority for everyone in the project. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSS development
Alon Bar-Lev wrote: Peter, quality is not absolute term. In computing I actually think it is; a high quality program does exactly what it is supposed to do and never anything else. Computers are very simple machines, so it is feasible for humans to create such programs. best algorithm good enough service and responsive to user's issues I, personally, for (3), providing a great service and responsiveness while perfecting the code as 2nd priority (exception are interfaces). I think this approach was taken at opensc in the past. It doesn't work unless there's lots of feedback from users however. I also like the (2) approach, while trusting the active core developers to define what is good enough, and if someone thinks otherwise he is free to become core developer or show the code of his alternatives to the point it is accepted by the core developers. Right, the real fun starts when the core developers actually don't agree on anything, or just have different areas of expertise. And pack mentality comes into play if the core developer pack is smaller than the opposition. Ideally the core developer pack is large enough to assimilate and mentor opposition before any conflicts, but personally I prefer to focus on code over trying to educate someone who insists on doing things their own way in any case. Agree on commits is not something that can become reality as without someone who can actually DECIDE, there can be non-ending arguments for each change. The definition of agreement would be that multiple people decide the same thing. We have this exact issue at OpenVPN project, which also reached a complete stop as it does not have core developers and clear responsibility for subsystems. I guess that perfect commits will still be included in the codebase? Programming is human creative work, there can be N^^N ways to acquire a goal, very hard to evaluate what is correct or better in most of the cases, it depends on the people involved and the people who actually review at specific point in time... I'd say that it must only ever depend on the users and never on the developers. But of course you are right in that developers must often try to judge what users want and need. Same change can be accepted at week X and rejected at week Y as other people review. Unfortunately yes, when there is not much agreement in the core developer pack. Because of that trust in the core developers of a project is essential, as it is the only constant factor in the process. But the trust doesn't materialize out of thin air. My point was that trust tends to come (at least for me) when there's also strong agreement. Not sure what this discussion was, but I wanted to comment your statement. Thanks for the comment - you make many valid points! It's a very interesting discussion, but of course we're already off topic for opensc since long. :) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSS development
Jean-Michel Pouré - GOOZE wrote: What I suggest is that OpenSC should be hosted on GIThub with write access to core developers (at least 5/6 people). Insisting on changing some hosting situation that has been set up is nothing but obnoxious protesting and spitting on the already established hosting. Centering development around github.com brings no benefits whatsoever over opensc-project.org. The latter allows the project to do nice integration and customization of all tools. Github not so much. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BT reader
NdK wrote: BT-readers Urgh... I wouldn't use a BT reader unless the card uses SM. It's trivial, if you sniff the pairing, to decode the whole BT traffic. And non-SM cards receive the pin as cleartext. http://ubertooth.sourceforge.net/ about ~100 EUR including shipping. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Viktor Tarasov wrote: I still propose to merge the SM branch into the github:OpenSC-staging and prepare it as candidate for release . It should not be difficult, recently both branches has been synchronized. The difficulty lies not in making something that builds, the difficulty lies in understanding every single changed line of code. There hasn't been very much review. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Failed to connect to card: Card is invalid or cannot be handled
Anton Svensson wrote: Hmm, what kind of info is needed? Dont have that much to be honest Full debug logs from pcscd and/or opensc? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Jean-Michel Pouré - GOOZE wrote: ease the collaboration process quickly or the community will set-up its own tools. Please stop blowing smoke. You want to fork so GO AND DO IT ALREADY! You clearly have no desire to work together with all members of the community. You've decided that only your own philosophy is the correct one, and you only want to work with those who follow you. All this while not sending an overwhelming amount of perfect patches, even for documentation, meaning that you have zero technical credibility. You are not in any position to make demands. You do not want to work within the established opensc-project.org structure, even though it allows you and everyone else to work quite freely thanks to Martin's effort of setting up gerrit and jenkins. Please go do your thing, but you obviously need to use a different name for your project. //Peter pgpwUiC0bQdin.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] How to deal with the gerrit backlog in an effective way?
Jean-Michel Pouré - GOOZE wrote: community, is there a way to agree to switch the 'public staging' to 'SM' and use it as a principal base for releases? I don't think there is. //Peter pgpmvOdeyPmxt.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] How to deal with the gerrit backlog in an effective way?
Ludovic Rousseau wrote: 1. rebase the SM branch over the OpenSC version in gerrit/staging Okay. So all we need is a diff between SM and staging? No. What you need is to extract all the SM patches and apply them on the gerrit/staging branch. Of course some conflicts are expected and need to be fixed. What I would do (but I am not a git expert) You got it exactly right the first time. git rebase does exactly this. For this work it might make sense to do interactive rebase in order to avoid duplicate work, but in any case rebase is the right tool. on the SM branch use: git format-patch origin to get the changes in individual patch files. on the gerrit/staging use: git am my_patch for all the previously generated patches. I would avoid doing this manually. git rebase really is the way to go. Do not apply all the patches at once but one after the other (in the correct order) and rebuild after each patch. The source code shall compile after each change or gerrit will reject it. This can actually be automated pretty easily after the fact. I would first do the complete rebase and only after test each commit on the branch. I had the problem yesterday: a compilation bug that was fixed by another patch. I had to merge the two patches. Another solution may be to reorder the commits. Interactive rebase makes this very easy once the commits have been found. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Viktor Tarasov wrote: How the 'staging', that you are working on, is related to the 'staging' branch of the OpenSC.git from github ? Looking onto the git workflow (https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy) I do not quite understand the place of 'staging' on the opensc-project.org . Output from gerrit must go into a local repository. This is the one on opensc-project.org. That repository is then pushed to GitHub every now and then. The GitHub repository should not introduce changes, but pull requests are fine, and will result in the commits in question being added into gerrit. Those commits will pass through gerrit and then be pushed over to GitHub. It's clearly possible to short-circuit gerrit and accept pull requests into the GitHub repository directly, but this should be avoided since it will cause unneccessary extra work, and because it means gerrit would not be used. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Ludovic Rousseau wrote:
on the SM branch use: git format-patch origin to get the changes
in individual patch files.
on the gerrit/staging use: git am my_patch for all the previously
generated patches.
I would avoid doing this manually. git rebase really is the way to go.
I am still lost when git rebase fails. I need to improve my git skills.
You mean if there is a conflict somewhere along the way? Then the
rebase only pauses, and expects the conflict to be fixed manually,
then:
git add fixed files git rebase --continue
..which will continue with the following commits or instructions from
the interactive rebase script.
Do not apply all the patches at once but one after the other (in
the correct order) and rebuild after each patch. The source code
shall compile after each change or gerrit will reject it.
This can actually be automated pretty easily after the fact. I would
first do the complete rebase and only after test each commit on the
branch.
How do you do that?
for c in $(git rev-list gerrit/staging..HEAD); do
git checkout master
git branch -D test_$c
git checkout -b test_$c $c
# run test here
test $? -eq 0 {
git branch -D test_$c
continue
}
# tests failed
echo TEST FAILED
git log -1 | cat
done
I had the problem yesterday: a compilation bug that was fixed by
another patch. I had to merge the two patches.
Another solution may be to reorder the commits. Interactive rebase
makes this very easy once the commits have been found.
Reorder and merge the problematic change with the fix. I know who to
do that :-)
I meant that the changes can also be reordered without needing to
merge them. Sometimes that's preferable.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Ludovic Rousseau wrote: Gerrit has more than 200 patches still waiting the the backlog. Many of them can't be merge since they do not 'fast-forward' and must be rebased by hand. Since the git commits were created without a Change-Id: we have 3 options (I think): 1. edit each commit message to add the missing Change-Id: and resubmit a rebased patch 2. reject all the patches rebase all the patches resubmit them as new gerrit entries 3. reject all the patches ask for new submission I did option 1 for some patches. It is very borring and time consuming. Without help (man power) I do plan for option 3. There's also an option 4, to decide that we want to change the configuration of gerrit to not require fast-forward, and work as if that change has already been done. This means reviewing existing changes and pushing new changes. When review is done and the change is good it gets +2 and may or may not be marked for submit. Once gerrit config has been changed all +2 changes would be applied in order, and a script could pick all up which haven't been explicitly submitted. The problem with this is of course that verification by jenkins will no longer be done for exactly the code that would end up in the repository. jenkins would run with $change added on top of current staging, but the actual inclusion of the change into staging may happen much later. Even if there is no conflict the code could still have changed in a way that jenkins does not catch. Requiring fast-forward completely avoids this problem. I think it might be a sane compromise to temporarily change the configuration, in order to more easily clear the backlog. But if we are to do so I think that there must under no circumstances be any new changes added (into staging) during that time. They can of course still be pushed to gerrit like always. I do not know if a creating a french OpenSC association to deal with the project governance will help here. Obviously not. But people with some free time can surely help move OpenSC. Yes, working on code is always the best way to help a project. The process is simple. Select a patch and go to its oldest unmerged ancestor. Then do: # a. create a merge branch git branch merge # b. go inside local merge branch git checkout merge Suggest combine the above a. and b. into: git checkout -b change123 staging Where change123 is the name for the new branch that will be created. # c. get cherry-pick a patch from gerrit git fetch ... # d. add Change-Id: git rebase -i HEAD~1 The above can be simplified to: git fetch ... git cherry-pick -e FETCH_HEAD ..which allows editing the commit message directly before doing the cherry-pick. If the message needs to be edited again, run: git commit --amend The command is git fetch https://www.opensc-project.org/codereview/p/OpenSC refs/changes/45/45/1 git cherry-pick FETCH_HEAD Instead of the URL it's also fine to put the name of the remote, in your example that's gerrit. # e. push git push gerrit HEAD:refs/for/staging # f. go inside staging git checkout staging Note that for the pull below to have any effect, it's important to submit the updated change in gerrit first. This means waiting for the verification, and then giving review +2 and finally submitting. In step d. the missing Change-Id: line must be added in the commit message. In the git rebase in interactive mode replace pick by reword Then add the Change-Id: given by gerrit. In this case Change-Id: Ifc3b467d8a299897bb7417c8dfd09873f24e46f6 as the last line of the commit message. Yes, very important. Thanks for the guide! //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
Magosányi, Árpád wrote: Graeme did some rework of the patch, but generally did not seem to agree with the review. The new solution included the addition of new API calls, however without any documentation. As anyone who has looked at the code and doxygen output, libusb is quite well documented, so the lack of documentation was obviously a problem. We are talking about lack of some documentation vs. a serious useability issue. As I explained, it was not and is actually still not evident in the libusb community that the bug was particularly serious (ie. that it was happening very often and/or for very many) since there was neither much activity following up on the original report, nor in the ticket. There has been significantly more activity for many other things. The way to address this is obviously not to shoot the people engaged in such other activity, but to make sure that your important message is heard loud and clear, when you have one. There have even been commercial inquiries for libusb-related projects, but none for this ticket. I am not saying that commercial inquiries drive my work on libusb, but they do indicate what matters to some others. Have you noticed it yet? I'm not sure what you mean? I personally have not experienced the bug. Yes, I use ccid, although only occasionally. Open source only works if you take responsibility for every single line of code that you are using. Open source only works if you understand both the technical and management issues. I am talking about what users have to do to make open source work for them. You seem to talk about how you wish projects to do management? This list is not about libusb development and I only tried to reply to the direct question about peer review for one particular libusb bug. Obviously there is much more detail to the libusb story than I can possibly write in a way relevant for OpenSC. I'm happy to discuss further in another more fitting media. #libusb on IRC or direct email or libusb list seem good candidates. The operational words being working and small here. I would very much appreciate if you study the work that has been done on libusb by me and other contributors in the last three years or so, before starting to talk nonsense about small work units. Unless you invest this time for thorough research I'm afraid you aren't in a position to make any remarks on the topic. I'm sorry if that sounds harsh, but if you've done the research I am convinced that you will see my point, and I will be more than happy to continue discussing off this list. It can be argued that a feature and its documentation are two different work units. No, not really, not for a library where documentation is otherwise quite complete. You will find out that leading a succesfull open source project have much more to do with effectively motivate people to do the work than being a good programmer, and sometimes aiming for the perfect code is the slowest way to get good code. I don't know about you, but I'm not at all interested in success if it means having to settle for mediocracy in software. Success means nothing if the software we output is anything less than the best we can do if we really apply ourselves. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
Peter Stuge wrote: So I would be in favor of letting main developers commit their changes to ONE SINGLE git staging branch directly and let developers/users fix the code. It's an interesting idea, but it places a significantly higher workload on the developers if there is more than one active at any given time, since instead of each person having to juggle only their own changes, everyone has to juggle everyone's changes. To clarify, the more traditional approach is to have repositories or branches for each developer in one central project location, even if these repos/branches have different topics. //Peter pgpX6ZQCe2MtD.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 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
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] 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
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
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] OpenSC and gerrit
Jean-Michel Pouré - GOOZE wrote: Unless you agree that by writing on the mailing list, we are going to incorporate an association. Jean-Michel, as I've said already, please stop the noise and go fork if that is what you want! I promise I'll stay far away. //Peter pgprOilbqPvTj.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] OpenSC and gerrit
Alon Bar-Lev wrote: I will try again. Thanks! It really helps! The bureaucracy and lack of flexibility will inhibit contributions and healthy *SMALL* community. What bureaucracy do you mean? Requiring no build failure and review in gerrit? I think those are acceptable requirements. They're also not exactly unique for OpenSC. Yes. That's exactly what I mean. Sure it is not exactly unique for OpenSC, just that you compare it to different kind of dynamics, different stability requirement and different amount of available resources. Do you think they are unacceptable requirements? I don't. What lack of flexibility do you mean? Anyone in the whole world can clone the gerrit repo, make changes, and push them back to gerrit for review. Right, then wait 3 months in order to have his changes reviewed and discussed, If review takes 3 months then I guess that's the pace of development for the project? Note that in addition to anyone being able to contribute changes it's also possible for anyone to contribute review. and only then continue, Can always continue. But yes of course if there are significant discussions to be had before any code can be written then that code has to wait until that discussion is done. I don't think this scenario is very likely. And even if it would happen, I think that some code would be a great way to spark discussion. It is however important to remember that the code at that stage serves primarily as inspiration for the discussion. Just because some code was written doesn't mean that it should go into the main repository. while doing about 10 times rebase and fix his 3 months old patch set. As I've written several times I'm not sure about the current gerrit configuration. It's also possible to configure gerrit for different workflows than the current one, specifically the requirements that changes must be fast-forward. There are both pros and cons with requiring fast-forward, as I've discussed in other messages. The other options clearly allow more flexibility but that's not neccessarily a good thing. Look, the model should be entirely different for small projects without much resources, something that is more similar to what we had before. There are 3, 4 or 5 core developers, they can do whatever they like, commit, revert, fix - anything. In practise this is the case for all users in the integrators group in gerrit. Each commit is sent to the mailing list, so peers and guests can review changes and comment. This is of course also configurable in gerrit. progress much faster, even in the price of committing not-the-best solutions, Do you find this a desirable quality for a security-related project? The guests' process can be replaced by the gerrit solution, which is superior. Instead of sending patches to mailing list use the gerrit interface to keep track and review. This is a great improvement, which is unrelated to core developers process. Yes they are somehow separate processes, but they can still share infrastructure and workflow without issues. What I basically saying is that in utopia you may be right, however, the reality requires flexibility, especially when the numbers are low (core developers, community size, allocated resources). I don't think I've advocated against flexibility, but I will if it means compromising on quality. Note that I'm not contributing much code, only speaking my mind on my preferences. What the new process provides is a stable branch [most chances] at every given time - this is its advantage and is suitable for software that should be released in very short cycles, this is not the case of this project. I don't know that gerrit is unsuitable even if longer cycles tend to be the norm. Until now I did not notice gerrit to be so good solution that all other methods should be dropped for of it. I'm afraid I don't understand what exactly you mean by this. Gerrit helps track patches. I'm not sure that the current configuration is completely ideal, but it is also not in any way causing a critical problem for further development. No, I meant there are other alternatives and solution for software development. gerrit way (or patch way) is one of them. I don't rule out the others just because the current trend of developing the Linux kernel uses one. The point about gerrit is not that it is trendy, the point is that it adds fantastic functionality. Of course there is no replacement for testing, but I really can not agree if you are arguing that being unable to extend jenkins is a critical problem for further development. No, I am arguing that it is more important than the whole patch method for core developers. Hmm? Can you be a bit more specific? Sorry, but I don't understand exactly. I quite miss the previous method in which people could work on this project progressing (and may do mistakes), but invest their time in proactive
Re: [opensc-devel] OpenSC and gerrit
Jean-Michel Pouré - GOOZE wrote: Jean-Michel, as I've said already, please stop the noise and go fork if that is what you want! I promise I'll stay far away. We don't want to fork, this would be stupid. Please understand that whatever you try to organize democratically will indeed be a fork. Open source is not democracy. //Peter pgpG4sexSJSop.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] OpenSC and gerrit
Jean-Michel Pouré - GOOZE wrote: Please understand that whatever you try to organize democratically will indeed be a fork. Open source is not democracy. Peter, you are shooting yourself a bullet in the foot. This isn't about me. As written before, some people really believe to own OpenSC. Something being written doesn't make it true. I further find it rather rich that you claim to know what someone else believes. Do you mean OpenSC can be ruled with passwords and administrative rigths? I mean that each and every open source project can be ruled by perfect patches! Democracy and passwords are equally irrelevant. Code is not. Creating a non-profit organization will solve this isssue and make sure OpenSC IS a democracy. This is an utter phallacy. An open source project can never be a democracy, and trying to create democracy is nothing but feelgood bureacracy. When the project was handed over to Martin, there was no discussion on governance and this needs to be fixed pretty soon. I find that quite offensive. Why don't you focus on the code? //Peter pgpEXC98lyj3F.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] OpenSC and gerrit
Viktor Tarasov wrote: I still propose to temporarily use the alternatives jenkins gerrit. It's IMO really stupid to fork anything, regardless if it is code or infrastructure. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Viktor Tarasov wrote: Could you explain here how can we 'move forward', preferably without appealing to the absent persons and to the non-working services? No, a move forward idea is broken from the start. Be specific. What is it that does not currently work and which is critical for developing perfect commits? I posit nothing. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and Project policy requires all submissions to be a fast-forward.
Ludovic Rousseau wrote: So I used the OpenSC documentation at [2] and rebased my staging branch (from [3]) onto gerrit/staging. Note that gerrit/staging is a so-called remote tracking branch, and it's best not to commit to those to avoid conflicts if other changes arrive from the remote than those you have made. It's best to do something like this before committing: git checkout -b staging gerrit/staging This creates a branch in the local repo called staging (the -b arg.) and then make new commits on that branch (or another, it's easy to make many of them). These branches are never touched by git unless of course it is specifically told to, but the remote tracking branches are used by git to synchronize with the remote, so it's better to not manually add commits to them. The commit pkcs15-profile.xml: remove empty SYNOPSIS section is now the first one on gerrit/staging. Ok, and git status says that you are 1 ahead? I edited the commit message to add a line: Change-Id: Id824eb62bc41f8f714bd6d67b6333ea07a527d70 to tell gerrit it is the same patch. Sounds good. Now I want to push this commit to gerrit. How do I do that? You can push the currently checked-out HEAD using: git push gerrit HEAD:refs/for/staging HEAD:refs/for/staging has local:remote format, so what is HEAD locally will be pushed into refs/for/staging remotely. HEAD locally always means what is currently checked out and refs/for/staging is gerrit magic that means proposed commit for the staging branch. [2] only says: Push your changes to be included in the staging branch git push changes gerrit:refs/for/staging git push some/branch gerrit:refs/for/staging git push one-commit gerrit:refs/for/staging This is backwards. gerrit is the remote and comes after push. Then there's the local:remote specifier where local can be a branch or a commit or HEAD, and remote should always be refs/for/staging. What is the correct command to push only one patch? I hope the above answers about the command, but this brings me to an important point: git push (and git in general) almost never operates on individual commits, but always on the commit including all of it's history. In practise this means that when you git push something you will not push only the commit you identify (using HEAD, commit hash or branch name) but in fact you will push also all ancestor commits which the remote repository (gerrit) does not already have. When pushing multiple commits at once gerrit records a dependency between the commits, which (with the current gerrit config on opensc-project.org) means that these commits must be submitted in gerrit in the exact order and in the exact version that they were orignally pushed to gerrit. Keep this in mind, and create separate branches locally for making changes which are unrelated. The way gerrit is currently configured it is however neccessary to serialize locally before pushing; before an unrelated change can be submitted in gerrit it must be rebased onto the current latest state of the gerrit repository. This is the awkward part I refered to yesterday. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and merge process: Submitted, Merge Pending state
Ludovic Rousseau wrote: Change 2 now merged. Ok! I also tried with change 3 https://www.opensc-project.org/codereview/#change,3 but I get the error: Gerrit Code Review 8:45 PM Change cannot be merged due to unsatisfiable dependencies. The following dependency errors were found: Depends on patch set 1 of I8b483369, however the current patch set is 2. Depends on commit 3a8519eda2704eceb2d27bfbeaca44c6da7d51b2 which has no change associated with it. Please rebase the change and upload a replacement commit. Do we now have to rebase all the patches? With the current gerrit configuration yes, unfortunately this is the case. Gerrit can also be configured differently, but I'm not sure if we want to.. In other projects where I use gerrit we do not have this rather strict policy, but it does also force contributors to pay attention to what they are doing, and if they rebase they should also look at the result of that, before pushing to gerrit again. In practise I don't know if it works; I didn't review the rebase of change 2, only the one for change 1. And while rebasing is easy in git I think it's bad that contributors are forced by gerrit to do it so much. On the other hand, changing gerrit to use submittype cherry-pick makes all dependencies merely advisory, ie. humans using gerrit must pay close attention so that nothing gets submitted out of order, or changes will have to be rebased anyway. What to choose depends on how the project will work with commits.. If we will generally have only very few very recent changes in gerrit then the current configuration can work pretty well, except that it must be clear already before pushing which commits will be submitted in gerrit before the one(s) being pushed. If we suspect that we will have some changes in gerrit which lay around for a long time without getting attention from either reviewers or contributors, and it was assumed by someone that those commits would be submitted first, then the someone will have to rebase, and everyone assuming that someone's change would go in will have to rebase in turn, and so on.. Not so nice. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and merge process: Submitted, Merge Pending state
Hi, Ludovic Rousseau wrote: I don't know if gerrit is broken or if I do not know how to use it :-) I would say that gerrit has some problem. Example with https://www.opensc-project.org/codereview/#change,6 The status is Submitted, Merge Pending. And has not changed since Feb 19 (one month ago). What is the next step? There should be no next step, you've done all that is needed, but for some reason gerrit has gotten stuck. It might be differences in gerrit configuration from when those changes were first added to gerrit to present day. I'm not sure. So I have to do something manually? This patch is the first one in a (long) serie. Unclear how to kick it loose. I made an attempt to kick change 1 loose. Since gerrit has complained that it must be a fast-forward on top of staging I made it so, and Jenkins built without errors, but at this point it needs to be approved and submitted again, since I have uploaded a new patch set. Let's start there? Please have a look and give +2 and submit if you still like what you see. (Patch is unchanged.) The detailed steps I did are as follows: cd /tmp git clone https://www.opensc-project.org/codereview/p/OpenSC cd OpenSC git config remote.origin.push HEAD:refs/for/staging scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ git checkout -b staging origin/staging git fetch https://www.opensc-project.org/codereview/p/OpenSC \ refs/changes/01/1/1 git cherry-pick -e FETCH_HEAD # IMPORTANT: Manually add Change-Id: I3a8519eda2704eceb2d27bfbeaca44c6da7d51b2 # at the bottom of the commit message. git push //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and merge process: Submitted, Merge Pending state
Peter Stuge wrote: I made an attempt to kick change 1 loose. Ok, so that worked. It would work fine to repeat this for each change, even if it is a bit labour intensive at least now, to clear the backlog. I've done it also for change 2 now. As you may recall, approving and submitting the change can be done also via ssh: ssh -P 8882 www.opensc-project.org gerrit review $commithash \ --code-review +2 -s I really like this interface to gerrit when patches need no comment but are good to go as-is. The way our Gerrit has been configured it enforces linear submission of commits to the repository, ie. everything must be submitted to the git repo in the same order changes were pushed to gerrit by contributors. This is in itself not a bad thing since it forces contributors to pay attention to changes in the codebase and what commits goes into the repository, but it does slightly raise the bar for less experienced git users. It's not really difficult, but it's one more thing to keep track of; make sure that your commit has the correct parent before you push. From practical experience with gerrit in several projects I tend to prefer the cherry-pick strategy when submitting changes. This means that stuff can be included into the git repository in a different order than was pushed to gerrit. It also means that humans need to pay more attention to not submitting changes in the wrong order when they are interdependent. The current config makes it impossible to do something wrong, but can in some cases create extra work for rebase and review. The cherry-pick merge strategy makes it very easy to do something wrong, but can save extra work with rebasing and reviewing+submitting of updated patch sets. The current config has strong arguments, even if it brings slightly more inconvenience. I actually favor not changing the config, even if we will have to rebase each and every change. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and merge process: Submitted, Merge Pending state
Ludovic Rousseau wrote: I made an attempt to kick change 1 loose. Done. The status is now Merged and the change is available in git at https://www.opensc-project.org/codereview/p/OpenSC but not yet on git://github.com/OpenSC/OpenSC.git I guess github is synced only periodically. I note a bug/typo in the patch for https://www.opensc-project.org/codereview/#patch,unified,1,2,src/libopensc/internal.h In the Doxygen comment it should be reader instead of reder Ouch. Then please don't give +2 but instead -2 and don't submit but give review in an inline comment. I would then have fixed it and pushed an updated patch. The detailed steps I did are as follows: cd /tmp git clone https://www.opensc-project.org/codereview/p/OpenSC cd OpenSC git config remote.origin.push HEAD:refs/for/staging scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ Failed for me: $ scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ Host key fingerprint is ab:d9:2d:c0:2f:4c:4e:bd:10:03:bd:d2:ef:2f:4f:61 +--[ RSA 1024]+ | . | |. . | | o . | |. = | | o =S E | | * oo . | | = =... | | ++*o | | o..=+ | +-+ Permission denied (publickey). I added my SSH public key on my gerrit account but the access is still denied. So the username between local host and gerrit doesn't match. Check https://www.opensc-project.org/codereview/#settings And possibly add: Host opensc-gerrit Hostname www.opensc-project.org Port 8882 User yourusernamefromgerrit Then you can instead use: scp -p opensc-gerrit:hooks/commit-msg .git/hooks/ (And ssh opensc-gerrit gerrit review ... for setting code-review and doing submit.) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and merge process: Submitted, Merge Pending state
Peter Stuge wrote: The current config has strong arguments, even if it brings slightly more inconvenience. I actually favor not changing the config, even if we will have to rebase each and every change. Thinking again about this, there's another possible problematic situation which I don't like as much.. If there's a long list of changes which haven't been reviewed yet, and review starts with some older change, and review results in that older change being updated, as I've done for changes 1 and 2 now, then *every* change after that one has to be updated, and they have to be updated in the order that they will be submitted. This is a bit awkward.. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Douglas E. Engert wrote: change,44 below is Vicktor's, not mine. I should not have said I think I have to rebase the code, and do another pull request? You can also 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] Upgrading aPass2003 Firmware to PIV
Anders Rundgren wrote: I don't know what USB P11 is, can you send me a pointer? It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. The same USB device could support Crypto-API primitives too. Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. Provisioning is indeed outside PKCS#11 and could be done in some other, also convenient, way. USB is really easy to use. I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. I fear that you are ahead of your time. :\ Adam Dunkels implemented the internet of things many years ago, but I don't even have IPv6. Things are changing, but still slowly. it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. Actually neither, I refer to the entire stack of software required for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. If there's a superior alternative Microsoft may well catch up at some point. They did with USB. But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. Also agree. I'm also not suggesting Feitian to pick up on my idea. If they do that's perfectly fine and totally awesome, but I'm keeping the idea alive only because *I* think it is good and would like to try it out. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Douglas E. Engert wrote: I am new to Gerrit too, All right! I'm by no means an expert, but I have been using it in several projects for a while, where I also helped with issues during the migration, so please feel free to ask any questions. but it looks like if 2 code reviews give a +1, the code will be advanced. See: https://www.opensc-project.org/codereview/ Need Code Review +2 means that one +2 review is neccessary. 2x +1 is not equivalent. I can use my Google OpenID to Sign In, and today did a code review on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags Thanks! Although since it is your patch it is perhaps a bit redundant, since you have likely reviewed your patch locally before sending it anyway. This is a change I submitted in December, and Victor gave it a +1 So today I gave it a +1, (As I am the only PIV developer I figure I can review my own code) I expect every developer to review their own code locally, already before pushing to Gerrit. The fact that you're the PIV expert is inconvenient to formalize a set of rules for, so it's something integrators will simply have to keep in the back of their head, as they look at individual changes. Looks good to me, but someone else must approve But this does not look like it is the same as Looks good to me, approved Indeed, the latter is a +2 code review. https://www.opensc-project.org/codereview/#admin,group,7 says Ludovic and Martin are the two members of the Integrators group. Right, this means that they are able to submit or integrate changes from Gerrit into the OpenSC repository on GitHub, by selecting +2 Looks good to me, approved during review, and clicking the Publish and Submit button, which is available in the web interface. Ludovic: Keep in mind that selecting +2 and clicking Publish Comments is *not* sufficient to integrate that change. Gerrit is a young tool still. :) I personally strongly prefer the SSH interface. If I was an integrator, I could have included your change with the command: ssh -p 8882 www.opensc-project.org gerrit review 51630a844e8e95e7108cb1966c5f3e21b93a463b --code-review +2 -s The hash after the review command is the patch set commit hash. Combination of Change-Id and patch set number should also work, i.e. ssh -p 8882 www.opensc-project.org gerrit review I51630a84,1 --code-review +2 -s although I haven't had success with this anywhere yet. (May be due to old an buggy versions of Gerrit!) https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy says: Git write access is granted to those who GetInvolved with OpenSC development and ... This would imply that there is no intent to keep write access controlled, but it might be controlled today based on the Gerrit access control. Gerrit behaves just like a Git repository, and for those more comfortable with GitHub it's also possible to fork OpenSC there and work from that. Git write access is almost nonsensical because Git allows everyone to write everywhere. Ludovic, Can you verify if you are in the Gerrit Administrator's group? and are any of the other people listed on the GetInvolved page listed as integrators, or admins? Integrators is only Martin and Ludovic, hence those are the ones who can currently include Gerrit changes into OpenSC on GitHub. Now for the third time, I'm sure that everyone who used to have repository write access will also quickly be added to the Integrator group if they mention their account name or ID and someone in the Administrators group is around. If only Martin is admin, then I guess there's a bit of a wait state, but that's not really such a big deal, because it doesn't block further work in any way. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Anders Rundgren wrote: It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Maybe you would like to have an STM32F215-based token? 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES It may happen this year. That's nice, although I'm not crazy about stm32. I tend toward NXP LPC. But so far, the closest to what I want and which is available is Gnuk: http://www.fsij.org/gnuk/ ..which also uses stm32. The development situation for stm32 in particular for USB is not amazing it seems. I haven't looked very deep in the datasheets yet. Gnuk implements CCID and so on in order to be interoperable with software stacks (in particular GnuPG) *today* but like you I'm focusing less on the right now and more on the right way for the future. :) The nice part about Gnuk is that it has all the primitives in place, even if it is only a slow software implementation, so I would really only have to focus on the protocol/API, which actually is exactly what I want. :) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Douglas E. Engert wrote: I have not tried this, but check out this token too: http://www.goldkey.com/usb-smart-card-with-piv.html Built-in PIV Support Basic functionality and support for PIV cards and tokens already exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. It does not say what what the Linux support is, but I bet it is OpenSC. I like the mechanical design very much, but not really the other aspects of the product; closed, they favor key escrow, and talk about their Master Token products raises some question marks which I believe will never be answered by the company. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Hi! Jean-Michel Pouré - GOOZE wrote: It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Feitian offers two ranges of products: CCID (ePass2003 and other products) and HID over USB (ePass2001 and other products). Don't get me started on HID. :) The libusb FAQ http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass tries to give an overview of the considerations for using HID. Executive summary is that it's a bad idea if you want to run on anything but Windows, and even there it may not be a very good idea because you have to re-implement some features which USB otherwise offers your protocol design for free. At Gooze, we have HID over USB products in stock (around 100 unused tokens) but we did not released them as they were incompatible with OpenSC. Under Windows, it seems that HID over USB range of products can be used without drivers, just over USB. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? Under Linux, a small proprietary USB framework is needed. Proprietary? You know that I think that's the wrong approach. :) The FAQ page mentions HIDAPI which can be used to communicate with HID class devices in some cases, but if portability is a concern, it should be clear from the FAQ page that using HID is not the best choice anyway. If this is what you mean, Sorry, no, it's not. What I have in mind is to implement the actual PKCS#11 API directly over USB, as far as that is possible. Again, issues have been pointed out with doing this, but I still think it's worth a shot. IMHO, CCID is superior as it is really plug-and-play under all systems. So much software is running which is completely unneccessary. I agree that CCID has sufficient usability, but it is by far not the best that can be done. Pure plug-and-play never exists, It does, actually. At least in Windows and Linux pure plug-and-play would be possible with my USB P11 idea, but I believe also in other systems. As always with PKCS#11 it would be neccessary to point applications to the correct PKCS#11-provider file (.dll or .so) but still I find the idea worth exploring. What we need is: * Cheap hardware available worldwide, with onlines sales. Yes, and the logistics of this can be tricky, but as you know with some volume it can indeed be done. And if the solution is good enough I think the volume will come. * A common framework under all systems, this is OpenSC. I'd be much happier without any framework at all actually. * Compatibility with all systems, including Linux, Mac, Windows and Android. Yes, the portability is important. iOS would also be nice, but well that may be pushing one's luck. :p From my point of view, I would be more in favor of an Android phone acting as a CCID device overs some secure wireless link over OpenSC. As you probably know, anything wireless is a quite significant attack vector. No secure transactions there please. But with a cable maybe. However, Android devices so far do not have a strong history of local IO either coming in or going out. :\ This can change along with market demands of course, but it raises the barrier for development. GOOZE will soon release crypto chips for Android What kind of chips? How do they connect? The only reason why Apple removed smartcard support is that (in my opinion) it may be working secretly on a new iPhone replacing smartcards and offering secure payment. Yes, I think this is a common belief, and I don't think it's wrong. The target for new OpenSC developments should be smart phones. Much of OpenSC doesn't really apply in smartphones, but I agree that smartphones may be very relevant security devices. //Peter pgpLnKnaGHQ64.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] USB token firmware
Jean-Michel Pouré - GOOZE wrote: http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass I wron't discuss as I don't know if improving HID for GNU/Linux is really time consuming. Hopefully you read the page anyway to find out about the considerations for HID. It may still be relevant even if the HID token is a little older. The HIDAPI library created by Alan Ott is as easy to use as it gets for HID class devices with Linux. The Linux kernel since a long time offers an API which can be used without any drivers and also without libusb, but the API has limited capabilities, and depending on the device they may not be sufficient. Then it will be neccessary to use libusb instead, and udev must be configured to allow the user to disable the kernel HID class driver. I believe HIDAPI now supports not only using libusb but also the kernel API. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? CSP and PKCS#11. OK! Yes, then the idea is similar to mine, except I do not like to use HID in order to reduce portability issues. HID has advantages for Windows but is more complicated everywhere else. (It can even be impossible on Mac OS X. Apple changed the policy for replacing the kernel HID driver in 10.6.) Just contact me privately and I can ship you a free HID token for testing. As you are the wizard of libusb, you may be able to judge and maybe find a solution to communicate with the tokens. No need for token, but thanks for the offer! :) The code that already supports the device is instead what I would look at. Is it available online? //Peter pgp48aJSg2TtO.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] USB token firmware
Jean-Michel Pouré - GOOZE wrote: No need for token, but thanks for the offer! :) The code that already supports the device is instead what I would look at. Is it available online? Sorry, it is not publicly available. You mentioned that one component is the small proprietary HID code for Linux and that part is of course not available, but it seemed like the other parts might be? Or did I misunderstand? Can you say more about the software on Linux for that token? I am confused about this discussion, because at first you ask us to flash the ePass2003 with another firmware, Oh, no that was Anders' suggestion. Maybe that's the confusion. I agree with him that as far as existing card/token standards go, PIV is indeed likely to be well and widely supported, but I don't have any opinion on changing the ePass2003 firmware. then we tell you that Feitian HID tokens are already available and you are not interested because ... kernel driver is not perfect under Linux. I'm not interested in having yet another token laying around. :) But I am however interested in the protocol! And I would look at the Linux software situation for that HID token and I would maybe also be able to find improvements. I just don't need the token to do that. At GOOZE, we stick to CCID. I think this is smart, especially if the Feitian HID token is an older product and no new HID token is planned. Good luck with your project. Thanks! The idea was always only about a protocol optimized for security, usability and portability, and it still needs rd, so please don't get the impression that I am trying to make someone else use it before I have shown that it works. I hope that we will be able to collaborate more on OpenSC main branch without being too picky on solutions. Don't worry, as you know I'm not a significant contributor. //Peter pgpTj3I69Q1It.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] USB token firmware
Peter Stuge wrote: You mentioned that one component is the small proprietary HID code for Linux and that part is of course not available, but it seemed like the other parts might be? Or did I misunderstand? I think I did. I read your email again to check. Can you say more about the software on Linux for that token? From your email it seems that the software for Linux may be completely proprietary. In that case it is of course difficult for me to make any suggestions. Is there any protocol documentation? //Peter pgpe8tVL9l885.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] OpenSC write access to main trunk, discussion
Jean-Michel Pouré - GOOZE wrote: 1) The ePass2003 code was reviewed by Viktor and included in his branch. You probably did not know, did not compile, did not test and therefore Viktor's work is ignored. This is appropriate in my opinion, because I do not think that the commits are ready for inclusion in the main OpenSC repository, regardless of the fact that Viktor has included them in his. He needs and deserves write access to OpenSC main GIT to speed up development. I disagree, if he considers the epass2003 commits I looked at to be of acceptable quality. The reasons is that we need more new features, more beta testers. You disregard the topic of code quality, which I think that is unacceptable in particular for a security related project. 2) Take the example of Alon developments around PKCS#11. A lot of them were ignored by OpenSSH. The reason is that when a small number of people have a grasp on a project, strange things sometimes happen. What? The reason is that, as you may know, OpenSSH is developed in the OpenBSD project, and their plans for PKCS#11 did not align with Alon's plans for OpenSSH PKCS#11 outside OpenBSD. Locking a project to a small number of developers is not good. There is no locking. Please get that idea out of your mind. Everyone can create commits. But as I have tried to give several examples of, obviously not every commit should automatically be included in the main repository - which is in principle what you advocate. IMHO, the way OpenSC used to be organized one year ago was superior, because there was a central repository with all new features. More beta features, more testers, larger market and superior quality. More code = more bugs. This is no longer the case and each developers works in his corner. If that is the case, it is so because the active developers do not communicate with each other. As you've mentioned, communicating is important. Committing to the main repository is never the start of communication, it is what concludes communication. The only collaborative work is what you call peer review. I'm not sure how much review actually happens. So my opinion would be to allow each developer to commit changes to the main GITHUB staging (developing) branch after discussion. Like it used to be the case using SVN. Replace branch with repository and I see no problem. But sharing a sandbox is significantly less convenient than each developer having their own repository/ies, while also exchanging commits with each other. It is perfectly fine for each developer to have one or even more repositories. Please understand that this is the nature of git, and actually the nature of development work. One person has focus on one thing at a time, in their corner. After they finish, it is of course important to do show and tell, get review comments, rework the code, and repeat until consensus. And make sure OpenSC is not only owned by one or two people. This cannot ever happen, we don't agree with this privatization. Who are we ? I don't care if OpenSC has just one committer, as long as code quality is a high, if not the highest, priority. The organization should be like: * 4/5 committers * 10/20 code contributors and developers * 100 beta testers The problem with this organizational diagram is that neither you nor anyone else can magically generate competent developers with lots of spare time. People contribute what they can when they can. You can of course hire developers, but if your recruitment process is strict, so as to find only really competent developers, you will discover quickly that they are quite rare. //Peter pgpBy0XBht722.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] OpenSC write access to main trunk, discussion
Viktor Tarasov wrote: Nobody doubts that review in critical. But what shall we do now, how can we 'move forward', if the review/acceptance process is stopped at the Gerrit level and the only person that is capable and has authority to do something is absent for a long time already ? I suggest to iterate over proposed patches until they are perfect. That way, those who can submit commits in Gerrit (this is the Gerrit term for including a commit into the main repository) will need to spend close to zero time on doing so. Their job becomes so easy that it is a no-op. Then it also gets done quickly and frequently. This must be the goal. Probably you have a reason -- 'whitespace', 'commit messages', 'undoes unrelated changes', ... But from my point of view: - commit history do not needs to be perfect for the new driver, before it's commited into one of the official branches; Work in progress will always exist. Beta testing of work in progress is good and important, and Git makes this extremely easy. Anyone in the world can publish their work in progress. Proposing a commit for inclusion in the main repo is something quite different. Whenever something is pushed to Gerrit it must indeed be perfect, or it is just some lazy or sloppy developer wasting the time of others. I think we are all busy and want to avoid wasted time. - personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits, but to not make the 'ping-pong' last for ages; This is a trade-off. It's fine to do this once or twice for a new developer. It's however quite hopeless when the developer whose work you review consistently makes the same mistakes that you have corrected and possibly even pointed out several times before. It is a waste of time for humans to do such work. Static analysis of commits, e.g. using checkpatch.pl from Linux possibly with som modifications, can and must be automated. Gerrit is the perfect place to do it. - historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' . I find this problematic since it leads to low reusability. Even just visual style differences are not really helpful. A uniform codebase is more coherent and easier to deal with for everyone involved. The coding style rules do not have to be very many, but having project wide rules is a good thing. Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous and finally to not block the 'moving forward'. Until newbies can demonstrate that they have learned the right things they are by definition not moving forward. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Anders Rundgren wrote: For non-government tokens like the excellent Feitian Epass2003 I would consider another approach: Updating the firmware to emulate PIV so that we can put the middleware aside once and for all. I agree completely that all the legacy involved in tokens and cards is horrendous waste of engineering resources, time and life. I'm excited about the gnuk project, it's a nice platform to play with the PKCS#11 over USB idea, which I refuse to give up on before having attempted to implement it and failed. :) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Jean-Michel Pouré - GOOZE wrote: Until newbies can demonstrate that they have learned the right things they are by definition not moving forward. Come-on, we are not in a class-room or in an administration. We are also not in a democracy. We are in a security related open source project. We all agree that Gerrit is the solution. So let's make it work and open accounts for recognized developers to make sure simple patches are committed. Everyone can register an account, which then allows to push commits into Gerrit, and to comment on and perform +1/-1 review of other commits. An OpenID is neccessary. If someone does not have an OpenID and would like me to provide one, feel free to send me your prefered username, md5(yourpassword) and your full name and email address, and I will create an identity for you on my OpenID provider. You then add two meta tags to any web page that you control, and the URL of that web page is your OpenID identifier. Note that many sites such as SourceForge, Google, Yahoo, etc. already have OpenID providers, so if you have an account there you can look around to find your OpenID identifier, which you then use to register with Gerrit. If this is not done within a reasonable time frame, I will create a Charity under French law open to everyone and we will have elections. Create as many charities as you like, I don't think it will make any difference. Working on code is unrelated to holding elections. I suggest that those who want to contribute to OpenSC start flooding Gerrit with perfect patches that are so obviously perfect and that are approved by so many contributors that they require nearly zero attention from Martin and Ludovic, and thus can be submitted (again, the Gerrit term for including in the main repo) very quickly. The only alternative to that is IMO for those who want to do development with a different goal and/or a different method than Martin and Ludovic to create a fork. Actually this is already what happens when using Git. Every repository is already a fork. Forking isn't neccessarily bad, but keep in mind that you will have to work very hard to be able to replace the de-facto standard. It will be significantly easier to focus on working with the existing project, on the terms of the existing project. Whenever a fork is created, it is important to decide right at the start what the purpose will be. If the purpose is to get changes back into the original codebase then it is obviously critical to follow the procedures and practises of that codebase, otherwise the effort will be wasted, since the forked codebase is unmergeable. Maybe someone wants to spend time fixing it up. This is very painful, and a complete waste of time. The alternative is to go full steam ahead and decide to never look back. Only with this attitude does it really make sense to fork. You already indicated that you don't really want to fork, so I guess your choice is made. This is all politics. Let's disregard the politics. That leaves code. It is impossible to argue against a perfect patch. //Peter pgpB0rSN7Du1v.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] OpenSC write access to main trunk, discussion
Viktor Tarasov wrote: Nobody doubts that review in critical. But what shall we do now, how can we 'move forward', if the review/acceptance process is stopped at the Gerrit level and the only person that is capable and has authority to do something is absent for a long time already ? I suggest to iterate over proposed patches until they are perfect. Iterate with who? There is nobody on the other side of the wire. For months the only person that is capable to do/answer something is absent. Martin is not the only person who you can talk to about code. Try asking the mailing list, and if that fails it is always possible to do self-review and iterate locally. That way, those who can submit commits in Gerrit (this is the Gerrit term for including a commit into the main repository) will need to spend close to zero time on doing so. Their job becomes so easy that it is a no-op. Then it also gets done quickly and frequently. This must be the goal. I'm completely agree with you, and admire the beauty of your abstract considerations, but what have we do here now, in our current situation -- Jenkins is dead, Gerrit is in mute coma. Jenkins may have a problem, but Gerrit looks like it is functioning fine, at least now. It is trying to merge commits which have been pushed, reviewed and submitted for merge, but where the commits have been pushed with dependencies, and where the dependencies have not yet been reviewed and submitted for merge. Here is where perfect patches make all the difference. The dependency looks wrong, and if there was no dependency, the commit would already have been included in the repository. Granted, Gerrit was introduced recently and will take a little getting used to, for people to learn the ins and outs. But in the end it is an incredibly helpful tool. Believe me, I have other interesting things to do. Yes, I believe you. :) But for months I'm looking the way to help to 'move OpenSC forward' and but had no answers -- there is no activity on the other side. I think everyone is on the same side. Decision to pull the ECDH, the ePass2003 into SM branch is my isolated desperate attempt to 'move forward'. :) Well, maybe nothing desperate is neccessary. Ludovic can submit commits in Gerrit to the main repository, so work on making the commits in Gerrit trivial for him to submit. I believe he will do it quickly. One very nice thing about Gerrit is that anyone can push an improved version of anyone else's work. In order to not make a mess, it is important to preserve the Change-Id inside the commit message, but everything else can change, both the rest of the commit message and the contents and the history of the commit. So for example: https://www.opensc-project.org/codereview/#change,7 has status Submitted, Merge Pending Ludovic has approved and submitted this change. Gerrit tries to include it, but a dependency is missing. Change 7 has one dependency: https://www.opensc-project.org/codereview/#change,6 which has been verified by Jenkins, but not reviewed and submitted by Ludovic. This change has no further dependencies. There are two ways to move forward on change 7: 1. Ludovic can review and submit change 6 for merge, which will then also make change 7 get included in the repository. 2. Anyone with a Gerrit account can fetch the commit in change 7 according to the download instructions, and cherry-pick it onto a new branch of the main repository, and then push that branch to Gerrit. This will make the change no longer have a dependency. Dependencies are created when a branch with several commits is pushed to Gerrit. Gerrit prefers that any branch being pushed is strictly for logically related commits. Gerrit prefers very many different branches, rather than only few. Fortunately, branches are fast and easy with git! After someone has done 2. above Ludovic will have to review and submit the updated change 7 for merge. So it seems more efficient to convince Ludovic to review and submit change 6, and then change 7 will automatically go in right after it. Repeat for all open and later added :) changes. Static analysis of commits, e.g. using checkpatch.pl from Linux possibly with som modifications, can and must be automated. Gerrit is the perfect place to do it. Please, come back to earth -- Gerrit is not actually functional. It looks good to me? https://www.opensc-project.org/codereview/ I've just registered and signed in. It works for Ludovic as well, and I'm sure he will submit commits as long as they need no further work. I don't really see a problem. - historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' . I find this problematic since it leads to low reusability. Even just visual style differences are not really helpful. A uniform codebase is more coherent and easier to deal with for everyone
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Jean-Michel Pouré - GOOZE wrote: We are also not in a democracy. We are in a security related open source project. Don't get me wrong. This is an organization issue. I am not talking about forking OpenSC, this would be stupid. Not neccessarily - if there is critical mass I think it is the only reasonable course. The website, teams and tools should remain. But we need a simplier and more effective approach. The tools (git and Gerrit) are as simple and effective as they can be. They are truly state of the art. That's the tools part. As for workflow, that will only be simple and effective when there is agreement on what is desired in the codebase. I consider it prudent to focus on quality, in particular for security related projects. That means that changes are not included on a whim or just because they are proposed. It means that development will be much slower than would be the case with a focus other than quality, e.g. a focus on rapid introduction of new features. Remember that under European law, all contributors hold a copyright on OpenSC code. The leader is not the copyright holder. When nothing happens in a project, we have the right to change leadership. Everyone has copyright, but actually that is not the key; the license already guarantees freedom for the code. Leadership is not related to the copyright, and since the codebase has a free license, actually change leadership is nothing other than starting a new project. Holding elections will allow to decide how to organize the project. No, not really. Holding elections may allow to decide how to organize a different project using the same codebase from the same copyright holders under the same or a compatible license. A fork. IMHO, a reasonable timeframe to fix organization issues should be around one month. We are today 19th February 2012. If within a month all these issues are not fixed, I will incorporate a Charity with other OpenSC members and call for elections of a board. I don't think you should wait. If you can find enough people to participate in the fork then as I said I think you should do it with determination; if there is hesitation then the fork is doomed to fail already before it has begun. I for one will stay at opensc-project.org and hope that it will never hold elections. What little I might be able to contribute I'd prefer to contribute to code. It's strange that democracy and bureacracy are proposed to move a software project forward, and that perfect commits isn't seen as a perhaps more effective path. //Peter pgpzT1owJhBL4.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] OpenSC write access to main trunk, discussion
Jean-Michel Pouré - GOOZE wrote: I created an account on Gerrit and looked at this URL: https://www.opensc-project.org/codereview/#q,status:open,n,z Some issues are marked 18 February 2012 with Jenkins user. So it seems we have GITHUB, Jenkins and Gerrit ... All this seems complicated. It's not so bad. I'll try to explain! GitHub stores the project output. This is where the current repository is published for the world to use, test, and base work on. Gerrit receives input. All proposed commits arrive here. It looks like there may be two ways for commits to arrive: 1. A developer creates an account and does git push directly to Gerrit 2. A developer signals the OpenSC repository on GitHub that they want to propose some change. Maybe this is done with a GitHub pull request. Note: I am not sure about this 2. I'm guessing based on the GitHub owner seen for many of the proposed changes. The Owner column on https://www.opensc-project.org/codereview/#q,status:open,n,z is the name of the person who uploaded the commit into Gerrit. Whenever Gerrit receives a change, it asks Jenkins to verify that the change at least does not break the build, but Jenkins can also do some further testing, such as checking the formatting and whatever technical checks are desired for proposed changes. Only Jenkins can set the Verified flag for commits in Gerrit, and nothing can go out to GitHub from Gerrit without Jenkins approving. Please advise: 1) How to push a patch from GITHUB to OpenSC staging directory. In two or three sentences. I would do: One-time setup: a. Create Gerrit account and add username and public SSH key b. git clone from github which has the patch c. cd into cloned dir d. Install commit-msg hook scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git f. git config remote.gerrit.push HEAD:refs/for/master For each patch: 1. Make the current branch equal to OpenSC GitHub + the patch (git rebase) 2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD 3. git push gerrit In case multiple commits belong together in the same logical change or that they depend on each other, then the current branch should have all these commits following the last commit of OpenSC GitHub. 2) Explain who is responsible of reviewing and you are going to extend the review team. Everyone is responsible for reviewing. All registered users can review all proposed changes, comment on each changed line, comment on the change as a whole, and give a score of +1, 0 or -1. Martin and Ludovic can in addition submit changes, ie. move them from Gerrit to the OpenSC GitHub. Obviously the job for Martin and Ludovic becomes much much easier if there are many others who have already given +1 score for a change. I am also just a user in Gerrit, like you and others, so I can't extend permissions for anyone, but I don't think doing that is very important. Focus on the code and everything else will fall into place. For non-government tokens like the excellent Feitian Epass2003 I would consider another approach: Updating the firmware to emulate PIV so that we can put the middleware aside once and for all. I agree completely that all the legacy involved in tokens and cards is horrendous waste of engineering resources, time and life. What??? Are suggesting that we should upgrade the ePass2003 firmware? This is ridiculous. Converging on a single implementation would perhaps not be such a bad idea, but I would personally prefer something without any legacy, ie. not even CCID. If you don't have time and resources, open the review team to the historical OpenSC developers, like Viktor and others. The whole world can do review. The more people that help with this, the less effort it is for Martin and Ludovic. The more people who help with review, the more people will be able to join Martin and Ludovic in submitting changes from Gerrit to the OpenSC GitHub. As I already wrote, I think that everyone who could commit before Gerrit was set up just need to mention their Gerrit username to Martin in order to also be able to submit changes from Gerrit to OpenSC GitHub. //Peter pgp6xBCPNU2ut.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] OpenSC write access to main trunk, discussion
Peter Stuge wrote: Please advise: 1) How to push a patch from GITHUB to OpenSC staging directory. In two or three sentences. I would do: One-time setup: a. Create Gerrit account and add username and public SSH key b. git clone from github which has the patch c. cd into cloned dir d. Install commit-msg hook scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git f. git config remote.gerrit.push HEAD:refs/for/master For each patch: 1. Make the current branch equal to OpenSC GitHub + the patch (git rebase) 2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD 3. git push gerrit In case multiple commits belong together in the same logical change or that they depend on each other, then the current branch should have all these commits following the last commit of OpenSC GitHub. This is my prefered way. I just found confirmation of my guess that a pull request sent to OpenSC GitHub will also arrive into Gerrit. So if already using GitHub then that is probably the easiest way. //Peter pgpNcKVnUNRsN.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] Upgrading aPass2003 Firmware to PIV
Anders Rundgren wrote: You didn't hear my presentation at FOSDEM 2012 but it was about creating a token with a standard API so that you would as a customer be able to just plug it in. This is an advantage of USB P11. In Windows 8 and later there doesn't even have to be a driver installed, since WinUSB comes with the operating system already and can be loaded automatically if the device follows some Microsoft-invented USB extensions. Only one PKCS#11 DLL is neccessary, and nothing more. it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. In principle I do not argue strongly against PIV, I generally agree with your observations. But it would be nice to try to do even better. :) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Jean-Michel Pouré - GOOZE wrote: With Git, anyone and everyone is a committer. The question here is flexibility: What flexibility is needed? My point is that everyone can easily create perfect patches, and given perfect patches which have been peer reviewed there is no need for flexibility as in lots of people with write access to the main repository. Even just one person can easily handle that effort, like Linus shows in the much larger kernel project. * OpenSC used to have a very flexible approach. OpenSC is NOT kernel.org with thousands of developers and no need for hierarchy. OpenSC is smaller, but I do not agree that there is no need for any kind of hierarchy. Now, please understand that this is not about power hierarchy as in politics, but it is about technical experience with the code and with the problem domain. I am personally familiar with the smart card domain but I haven't spent much time with the OpenSC codebase and therefore I absolutely do not want some patch I create to be included without being reviewed first. The review is criticial. Especially in a codebase like OpenSC, to which I might indeed delegate my legal authority, I want the review to be merciless. Don't make the mistake of believing that only people with write access can do review. It is quite the opposite. I have been trying to make this point many times before, but it seems difficult for many to grasp that all peer review is helpful and important for the codebase, regardless of who is doing it. Everyone who cares about a software can and should help with review. A side effect of doing review is of course that knowledge about the codebase increases in the community. After having done some amount of review, people might even get write access, because they have demonstrated that they can be trusted. This is demonstrated by finding difficult-to-spot problems in others' patches. It is not demonstrated by quickly giving every patch a thumbs-up. Some say that it feels pointless to do review for someone who does not have write access. I disagree with this, and I think this is a very dangerous, almost complacent, attitude. If you do not believe that your review is worth anything to those with write access, why should you yourself have write access? This becomes a negative spiral where in the end a project has no resources to do review, simply because people do not have enough self-esteem to believe that the review they can contribute matters. I don't know what the answer is. I've tried time and time again to convince people that doing review is helpful and important and a significant contribution to any project, but it often doesn't really stick. * Setting-up a compilation farm is no reason for closing write access to historical developers of OpenSC. I agree, but I don't think one has anything to do with the other, even if they happened at the same time. I guess that anyone who had write access to the repository earlier can get it again if they just send a public ssh key and their prefered username. * Discussions are the base of Free Software. Once discussions have occurred, there should be several people with write access. You have to trust people. No need to lock write access to the main GIT. I disagree about having to trust people out of the blue. Generally, people write really shitty software, and the poor way that a lot of open source software works is all the proof we need. I love open source, not neccessarily because it is technically superior, but because it allows *me* to fix things which are broken. I believe that open source is as good as it is primarily thanks to the practise of peer review. The purpose of more write access as far as I can see is to have faster, ie. less well reviewed and thus less well understood, changes in the main repo. I do not agree at all with that goal. From my point of view, OpenSC is becoming a semi-private project with two people in charge: Ludovic and Martin. Personally, I don't want OpenSC to be organized the same way as libccid. I find both Martin and Ludovic to be quite reasonable people. I've never had any problem discussing any issue with them, actually quite the opposite. If there are perfect patches (well reviewed, well understood) then I am convinced that they would race each other to add those patches into the repository. I have no experience from libccid development, but I'm happy with it as a user, so Ludovic must be doing something right. We demand more freedom and transparency or this can only lead to endless flamewars. Let's focus on a concrete problem. Have you created a patch which has been peer reviewed and is well understood, but has been rejected by Martin and Ludovic? If yes, let's try to find a solution. If no, you can't really demand more freedom and transparency, because you haven't exercised the freedom to create perfect patches yet. I did review the epass2003 commits when their availability was announced, and I've looked at
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Alon Bar-Lev wrote: This project loses its flexibility, this is not an advantage. I disagree. I find that Git allows all the flexibility developers could ask for. The cry for more committers is misguided. With Git, anyone and everyone is a committer. If commits exist but are not being included in the main repository then it is most likely because they need more work. The effort required to include a perfect patch is next to zero. The question is if a project will insist on perfect patches (e.g. Linux) or if anyone should be allowed to commit anything to the main repo. Inkscape apparently did the latter, and it resulted in a massive janitorial workload to clean up the horrible mess that had been created. No fun. Consider also that addition of commits without review will quite likely introduce bugs which would have been discovered by peers. I think this fact alone is reason enough for OpenSC to not include a single line which hasn't been reviewed rather thoroughly. The review process could even be formalized and made into a strict requirement before writes to the main repo are possible. I understand that Gooze and others have strong interest in inclusion of changes into OpenSC. The only way to make that happen is what Douglas described; put in the work, and create perfect patches. Write access to some repository is not the issue. The whole world already has Git write access. If someone needs help with publishing a repository then feel free to let me know. If you have prepared a patch which you think is perfect but noone is responding then give it a thorough review yourself, and try again. Also try discussing the change, explaining it in an email can be a great way to produce a better commit message, which is very important for anyone who is doing review. Note that review does not mean to browse through the change and say looks ok, but it means to understand the effects of every changed line. This can require a lot of context and/or research. You can help by that commit be included by doing review. You doing review is infinitely more important than you having write access to some repository. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Frank Cusack wrote: For example, if I had some key/cert on the card (and I know it can only exist on the card -- this might happen before it is shipped to me or in bulk secure provisioning on site) that is not able to be used for anything externally. ie, you cannot encrypt,decrypt,sign or verify any external data with this key/cert. But when you ask for a CSR, there's actually a CSR APDU -- not a software generation of CSR then asking the card to sign the CSR. You pass the relevant attributes to be included in the CSR, and the card itself adds some signed data as a CSR attribute which the CA can verify. There is no way for the user to add that signed data to a software CSR because the key used to sign that data is not available to the user. That's just a way I thought of, maybe there is some other way as well. The current (but under revision) Swedish eID card includes a scheme like this. The card is delivered with a special key+cert which is meant to authenticate the card when it is enrolling. So far for the theory. In practise I've seen zero software solutions use this key+cert. I guess there may be one at the police (they issue passports and this card) but.. It seems it would be a good advantage to be able to do this, you could provision on demand at an insecure station, instead of (e.g.) having a secure station and provisioning with a single-use PIN. OTOH you need special cards and special software on the insecure station. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Seriously, please trim replies. Christian Hohnstaedt wrote: Anything that can be signed by the card can be signed by a software key, too. Yes of course. But the point is that the card can come with the special key pre-installed. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Securing a 3DES key on smartcard
Jean-Michel Pouré - GOOZE wrote: Is there a way to store a 3DES key on smartcard, so it cannot be extracted but still be usable by OpenSSL? Maybe some card supports it, but usually it is undesirable for performance reasons. Symmetrical ciphers are usually intended for large amounts of data, so performance is more critical than with asymmetrical, and cards are *very* slow in comparison to the CPU. When creating a signature it may be OK to have one or a small number of relatively slow operations. RSA encryption often uses a symmetrical cipher (AES, DES, etc) for actual encryption of data, and then encrypts only the key for that cipher using RSA. //Peter pgp9OPfvSiltx.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] Slowness opening card
NdK wrote: But I noticed that lastly every command is sluggish. .. Is there something I should check or some more debugging I should enable? Probably libusb bug #56 which has been fixed but not available everywhere just yet. What distribution do you use? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
Martin Paljak wrote: It is possible to access Gerrit Git interface through HTTP (instructions pending) for pushing changes, also to check out code. Feel free to reuse stuff from http://www.coreboot.org/Git //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
Douglas E. Engert wrote: Is it possible to use: https://jenkins.opensc-project.org/ instead of https://www.opensc-project.org:/ https://www.opensc-project.org/autobuild/ https://gerrit.opensc-project.org/ instead of https://www.opensc-project.org:8881/ https://www.opensc-project.org/codereview/ .. So are you saying, I should get my network people to open ports 8881 and for me? No, you can use these URLs: https://www.opensc-project.org/autobuild/ https://www.opensc-project.org/codereview/ To access Jenkins and Gerrit respectively. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
Martin Paljak wrote: Here is an overview of updates to opensc-project.org plumbing and Git. Amazing effort Martin. Thank you so much for getting this done! Gerrit uses OpenID for authentication (google.com has one, as do many other websites) thus no new passwords needed. In case anyone needs an OpenID please send me an email with your name, your prefered username and md5(yourdesiredpassword) and I will make one for you. You will then need to add two elements into head on any web page that you control, and the URL for that web page will be your OpenID, which some other sites will show as your username. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Martin Paljak wrote: Key is to build pcsc-lite with support for openct. I guess you mean the opposite: build openct with pcsc-lite support. Yes, that's right. Sorry for the confusion. It would be nice if some OpenCT user would: - remove CCID support from OpenCT default build - make the pcsc-lite configuration semiautomatic pcsc-lite or rather the ccid package does not have all features of OpenCT. In particular the support for cm4040 only exists in OpenCT. I think it makes no sense at all to remove CCID support from OpenCT. The code is there and works and people can use it if they like to. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Niclas Hoyer wrote: thanks for your help. I just copied your entries in /etc/reader.conf and it worked! Unfortunately, it just worked once really well. OpenCT crashed somehow and now just responses with ct_card_lock: err=-7 I haven't seen this on my system, but OK, let's solve that problem. As I wrote, it works perfectly for me. Anyway, I just ordered a SCM SCR3310 to get things working. Um, ok, please let me know if I should spend time helping you to get the cm4040 working? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Niclas Hoyer wrote: Unfortunately, it seems that the tar file, that HID uploaded is not correct: $ tar xvf ifdok_cm4040_lnx_x64-2.0.0.tar.gz tar: This does not look like a tar archive Their web server is configured to automatically gzip compress file names which end with .gz, so you get a tar file that has been gzipped twice, and you have to manually gunzip it once in order for tar to be able to (automatically, without z in modern versions of tar) uncompress the second time. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Niclas Hoyer wrote: Um, ok, please let me know if I should spend time helping you to get the cm4040 working? Thanks for your help. I think I got it working now. I reinstalled openct and double checked /etc/reader.conf.d/reader.conf $ cat /etc/reader.conf.d/reader.conf FRIENDLYNAME OMNIKEY CardMan 4040 Socket 0 DEVICENAME /dev/null LIBPATH /usr/lib/openct-ifd.so CHANNELID 0 now I get: $ opensc-tool -a Using reader with a card: OMNIKEY CardMan 4040 Socket 0 00 00 3b:ef:00:ff:81:31:fe:45:65:63:11 ... So I think everything is working :) Ok, nice! One last thing: is it normal, that I have to jiggle the card a bit to get it working? It seems that the connection between the cardman and the card is not that reliable. Hm, I may have seen this once or twice, but it doesn't generally happen with my (refurbished) cm4040. Maybe the reader contacts have oxidized, or the plastic on the edges of the reader has been worn or damaged so that the card is not guided to the exact right location under the contacts, or maybe even the card contacts are worn? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Niclas Hoyer wrote:
I have set up OpenCT and cm4040 on a up to date full x64 ArchLinux
system. The only thing I had to do, after I installed
openct from AUR and pcsclite from the repositories was to first
comment out
#reader cm4040 {
#driver = ccid;
#device = pcmcia_block:/dev/cmx0;
#};
from /etc/openct.conf
By comment out I guess you mean uncomment? :)
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Andreas Jellinghaus wrote: I'm running a recent ArchLinux on a Thinkpad x60t and installed a CardMan4040 pcmcia card reader. OpenCT works, at least I get an ATR: Buy a real card reader, CardMan 4040 never worked right in all these years, as far as I know. Not so. I'm using one with great success since a couple of months. Everything works perfectly. I reported bugs with the unstable kernel driver, and IIRC the developer had moved on to more interesting topics already, so I guess those remain unfixed. What was unstable, and what was the issue? Is there still a kernel bugzilla entry? Who wants to use old and undocumented hardware, Documentation for the hardware is available, just not publically. The hardware is actually CCID, but wrapped in a thin PCMCIA layer. when there are nice alternatives with companies wanting to be supported and giving you support and documentation etc? Please vote with your money. Omnikey are a pretty nice company. Also, as I'm sure you know, there are not very many PCMCIA readers available. The 4040 seems by far the best for Linux, and as I said, I back that by zero problems. Niclas, I'll reply to your message with some details about my setup. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
Niclas Hoyer wrote: $ openct-tool list 0 CCID Compatible $ openct-tool atr Detected CCID Compatible Card present, status changed ATR: 3b ff 96 00 ff 81 31 ... Good stuff. This means kernel driver and OpenCT are all in order. In order to work easily with OpenSC and other software that might want to use the reader I would suggest to replicate the setup I have. I've built pcsc-lite with support not only for USB CCID but also for openct, and that is how OpenSC can reach the cm4040. 0x7fd1227f8700 19:33:54.493 [opensc-tool] reader-pcsc.c:1023:pcsc_detect_readers: returning with: -1101 (No readers found) No smart card readers found. .. So, why is opensc trying to talk to pcsc? I'm not sure OpenSC still supports OpenCT directly. Anyway, taking the detour through pcscd allows also other software than OpenSC to use the card, which was a requirement for me. Is there anything I have to do, so that opensc recognizes openct devices? pcscd needs a reader.conf to know about the reader: --8-- /etc/reader.conf FRIENDLYNAME cm4040 DEVICENAME /dev/null LIBPATH /usr/lib/openct-ifd.so CHANNELID 0x0 --8-- Then I simply run pcscd -f and can watch what is going on with the card. If I haven't run openct-control init, this is my pcscd output: $ pcscd -f Error: can't open /var/run/openct/status: No such file or directory readerfactory.c:1050:RFInitializeReader() Open Port 0 Failed (/dev/null) 1082 readerfactory.c:233:RFAddReader() cm4040 init failed. 00330333 tokenparser.l:175:LTPBundleFindValueWithKey() Value/Key not defined for: ifdVendorID in /usr/lib/readers/usb/ifd-ccid.bundle/Contents/Info.plist ^C $ openct-control init $ openct-tool list 0 CCID Compatible $ pcscd -f tokenparser.l:175:LTPBundleFindValueWithKey() Value/Key not defined for: ifdVendorID in /usr/lib/readers/usb/ifd-ccid.bundle/Contents/Info.plist ^C The plist error is harmless, everything works for me anyway. Key is to build pcsc-lite with support for openct. Watch out with udev rules if you also want to connect a USB CCID reader. That can be supported both by OpenCT and pcsc-lite. I choose to let pcsc-lite handle those in my system, so I have to take out the OpenCT udev rules so that OpenCT leaves them alone, but you may prefer to use OpenCT. Let me know if you have any questions. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initializing Feitan ePass PKI token takes over 60 seconds?
Ludovic Rousseau wrote: The good news is that a new stable version of libusb should be available soon. Oh cool. Thanks for fixing it. The patch has been available for a long time already, it has taken libusb a good while to catch up with all issues. Is it worth filing bugs with the distros and getting them to include patch(es) in their libusb packages? I don't think so. The libusb version 1.0.9 should be available soon. I would have made the release yesterday but I discovered several commits for Mac OS X that had fallen through the cracks and I hope they can get a bit of testing today or tomorrow. Filing bugs to get the 1.0.9 version into distros would be great, there are many bugfixes in the new version. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Alon Bar-Lev wrote: However, there are some advanced cards that can generate authentication token, so you can actually authenticate once using PIN get authentication token out of the card (many can be available at same time), then each transaction is authenticated using these tokens. This approach solves the PINPAD issue and BIO issues. And this works because the p11 library stores these cookies associated with each incoming p11 user? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
NdK wrote: One of the projects on my TODO list (quite a long list :( ) is to implement a suitable interface (CCID+virtual token? Could be better to opt for something that doesn't require APDUs...) on an embedded system w/ USB device interface... Right. This is the idea for a USB p11 token that I've been going on about for a long time already. :) I was thinking microcontroller size, but if you're using a more powerful USB device hardware that can run Linux then it could be realized pretty quickly using softhsm. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
