Re: [opensc-devel] MacOS 10.8 Mountain Lion and OpenSC
Hello, Taking a step at a time, I fixed building OpenSC.tokend cleanly (without errors and warnings) on 10.7 [1] [2] with clang and also documented better the fact that Tokend build makes use of binary components from Apple [3]. Regarding 10.8, I've heard rumors that OpenSC (or any other PC/SC based application) does not work with the latest developer preview - SCardEstablishContext fails and there's no pcscd binary on the system either. I don't have the preview nor would I be willing to debug it before the retail version is available, but this could be taken as a sign, that most probably 10.8 will be revolutionary and change everything we know about computing, at least when it comes to smart cards :) [1] https://github.com/martinpaljak/OpenSC.tokend/commits/10.6-0.12.2 [2] https://www.opensc-project.org/opensc/attachment/wiki/MacInstaller/tokend-build-10.7-fix.patch [3] https://www.opensc-project.org/opensc/wiki/MacInstaller#Binarydependencies On Sat, Feb 25, 2012 at 01:00, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Fri, Feb 24, 2012 at 00:15, Douglas E. Engert deeng...@anl.gov wrote: Is anyone planing on looking at OpenSC and Mac OS 10.8? especially in light of: http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html and http://www.macworld.com/article/165417/2012/02/apple_readies_mac_os_x_mountain_lion_update.html Regarding PKCS#11, I doubt there's much happening (I *heard* that the pcsc-lite version is still the same, but I'm not interested in trying out Apple betas). But regarding OpenSC.tokend, given previous experience with it and the lack of (public or NDA) documentation from Apple regarding the topic, definitely not before 10.8 has been demod on stage and actual *retail* copy is available. If anything, there might be a few things to keep in mind: - possible requirement to have signed binaries (and installer?) for OpenSC.tokend, if still supported - possible requirement to play together/through the appstore... - tokend/cdsa totally deprecated and a new replacement surfaces (which would render OpenSC.tokend useless on 10.8 anyway...) Martin ___ 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
Dear Peter, 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. Come on! This is obvious. When we mean bureaucracy, we mean a small group of people trying to privatize OpenSC. When the project was handed over a few months ago, there was no election. OpenSC copyright does not belong to you but to the group of people who wrote it. You have to right to stop us from developing OpenSC, making commits or publishing packages. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
The message was sent before it was written. Correcting it: Dear Peter, 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. Come on! This is obvious. When we mean bureaucracy, we mean a small group of people trying to privatize OpenSC. OpenSC copyright belongs to the group of people who wrote OpenSC, which is all of us. It does not belong to any company and an individual granting rights to other individuals. To be more precise: Peter, Ludovic and Martin do not have any legal right to establish rules over OpenSC project. Especially if these rules go in the direction of more bureaucracy. We have to accept collaboration whenever possible. If you still don't understand, we will go over an election process. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Managing the queue line of a compilation farm
Le samedi 17 mars 2012 à 22:15 +0100, Viktor Tarasov a écrit : Excellent, I will prepare the guidelines for the procedure. Thanks. Perfect. During the week-end, I installed a fresh Super-micro server at the office. It is running a Debian x64 with encrypted file system on a 60G solid state drive. The hardware is running with an IPMI card providing cold/hot reset, serial over IP and monitoring to ensure the server is always up and running. It is running on electrical backup for 24x24 operation. So we stand ready to provide the first packages whenever needed. You should not be disappointed - the naming policy is open for suggestions. The current one is just the rapid 'working' solution. This is a translation problem, sorry. I am not disappointed. :) About naming, I would suggest to mimic VLC lightlies, at this URL: http://nightlies.videolan.org/build/win32/?C=M;O=D For Windows: opensc-$version-$branch-$mmdd-$hhmm-$platform-$debug.$suffix For Mac OSX: opensc-$version-$branch-$mmdd-$hhmm-$platform.$suffix Where: branch = staging or sm if we have two branches, or simply git if there is only one branch. version = 0.12.3 (major-minor). mmdd = 20120319 (19 March 2012) hhmm = 0112 (one hour 12 minutes) platform = x32 or x64 debug = debug or none. suffix = 7z, zip, exe or msi So we can have as many compilations as needed during the day. To comply with Debian rules: We may have to add a leading O- to the Debian versions. And set priority to zero. We have to think about a simple way to accommodate with several GIT versions. Maybe it could be a virtual apache host, i.e. gitversion.domain.org. So we can provide different APT repositories. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Managing the queue line of a compilation farm
Hello, On Fri, Mar 16, 2012 at 11:14, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: GOOZE is working on a compilation farm to compile OpenSC and pcsc-lite/libccid for the following platforms: GNU/Linux: * Debian sid 368/amd64 * Debian wheezy 368/amd64 * Debian squeeze 368/amd64 * Ubuntu precise 368/amd64 * Ubuntu oneiric 368/amd64 * Ubuntu natty 368/amd64 * Ubuntu maverick 368/amd64 * Fedora 15 * Fedora 16 * Fedora 17 * Cent OS 6 * OpenSuse 12.1 * OpenSuse 11.4 Excellent! Providing different Linux packages outside of their native environments (official package trees) would be a nice thing, especially if not so common platforms can be used. At the same time, maintaining *installable* packages (repositories) and debugging them if things go wrong is a time consuming task. From usage statistics in .ee there are some distros on your list that have maybe a single user :) Compiling against different versions and different environments is good and the more varied the installation base is, the better different gotchas can be caught. But for optimal results, the outcomes should be tested as well (I guess the actual compilation-time differences are within minor versions of gcc/clang/pcsc-lite/openssl) Connecting a dedicated smart card reader + smart card and running some automated tests in addition to compilation on each and every platform, that would be a real cherry. Martin ___ 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
Hello, On Sat, Mar 17, 2012 at 23:01, Viktor Tarasov viktor.tara...@gmail.com wrote: Gerrit still has replication problem -- 'staging' of OpenSC/OpenSC.git do not updated by merges of Gerrit's repository. Certainly, gerrit is nice tool to play with, but, without replication it looses much of it's utility. This was due to the ruby github ssh issue [1], after what all pubkeys were suspended on Github and needed validation. So was the key that did the syncing disabled. As the repostiroy did not seem to be out of sync, I assumed that the keys are still OK and re-enabled them. That should also bring the sync back (will verify). [1] https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SmartCafe Expert 3.2 72K works fine in some versions but is an \unsupported card\ in other versions.
Hello all, I just started trying to get my muscle card (SmartCafe Expert 3.2 72K) working with OpenSC and am having the same problems as Thomas reported. I am currently using Mac OS X 10.6.8 (and Windows XP) and OpenSC 0.12.2. I tried to get around the problem by editing opensc.conf and adding the following with no real success: force_card_driver = muscle; All the above did for me was get opensc-tool -n to report MuscleApplet. When running pkcs15-tool, I get binding failed: Unsupported card. I also saw that there is an open bug on this. Ticket #403 - OpenSC no longer works with musclecard and/or multiple drivers Has there been any progress on this issue? Thanks, -David Muoio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
