Re: [opensc-devel] new release?
On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
On 04/30/2012 12:06 PM, Jean-Michel Pouré - GOOZE wrote: Most of the development is happening in the secure messaging branch and installers are released from the compilation farm. [...] We will soon release a testing farm with smarcards and USB tokens attached. So you can safely go with the secure messaging branch. Hi Jean-Michel, Thanks for your reply. What I am looking for is an official release, something that Linux distributions could pick up. A snapshot of another development branch wouldn't really help me here, but I appreciate the suggestion. I'm sure there's a lot of nice work going into the secure messaging branch, but that shouldn't stop the 0.12.3 release. There will always be some great new stuff to merge, but it's also important to be able to get regular releases out, based on the already merged code. -- Thanks, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] new release?
Hello, The staging branch has some nice changes, in particular I'm interested in Stef's mlock fixes. Would it be possible to have a new opensc tarball release off the staging branch, please? P.S. Why is the development happening on 'staging'? In most open source projects the 'master' branch is the development branch, which a lot of people have come to expect. -- Thanks, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Code flow for Git branches / code review
On 06/09/2011 09:24 PM, Martin Paljak wrote: The situation I'd like to create is where there are, in fact, several virtual forks of OpenSC inside OpenSC project itself (how meta!). Be it a fork for every developer (now also called a maintainer) or a fork for feature branch. And make it so, that in fact any of those forks could become the master for the next release. (In fact, I'm thinking about a script which takes a Git commit hash as the argument and automagically helps creating the release, meaning doing the boring work of moving right files from nightly builds directories to proper locations, generating checksums etc) 'in fact any of those forks could become the master for the next release.' This is going to be very confusing for outside contributors. I would instead suggest having a canonical central repository. Although git can operate in a fully distributed setup, having a central repo is for HUMANS so that they actually understand what is going on. Github has a concept called organization for hosting projects where several people have access. With such setup, you could move all the opensc related projects (opensc, libp11, openct etc.) to github's OpenSC organization, and give access to several people for merging patches and forks. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Merge of opensc-user and opensc-devel.
On 05/25/2011 03:48 PM, Martin Paljak wrote: Hello subscribers, As laid out about one year ago, I'd like to merge opensc-devel and opensc-user mailing lists a few days after OpenSC 0.12.2 is released on 10.06.2011. I think it's a good idea, there's little practical value in keeping these two separate. After all, opensc (and the PKCS#11 API) is targeted for developers and not for end users, so the topics of the two lists are bound to overlap. [...] If you have any *practical* concerns about this merge, please voice out now. Please don't change the List-Id and other identificators of the new opensc-devel list, in order to avoid breaking any mail filters that people might have. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Gnome smartcard manager
On 03/13/2011 03:52 PM, Mr Dash Four wrote: In short and from what I remember, the OpenCT/OpenSC versions shipped by Fedora were too old, introduced an unnecessary dependencies and, most importantly, it didn't work with my smartcard at all (even though the card was not that uncommon, as it turned out). Fedora has been shipping latest released opensc for quite some time. You got your smart card working by building the latest opensc development code from the SVN; that's not what Linux distributions are expected to ship. The way Linux distributions pick up new code is by building the officially released tarballs. Now, the real problem why Fedora (and other distros) didn't support your card is because OpenSC had some release management problems and it took quite a lot of time to come out with the 0.12.0 release, while the 0.11.x was getting too old. Martin, are there any plans for 0.12.1? There are some important bugfixes in the SVN and several people have been asking about the release. I would really like to have Fedora 15 ship with OpenSC 0.12.1 if possible, but that'd mean a new opensc release very soon. snip Given all that, I had to compile everything from source (imagine the number -devel dependencies packages I had to install for this!), build gdm 2.32 (on FC13!), build openct/opensc drivers from source while strip the dependencies I do not need and eventually made the whole thing work If you are building your own custom distro (yes, that's what an initrd basically is) then building some stuff from source is the way to go. But for a general purpose Linux distribution's point of view, it makes sense to support as much as possible use cases, even if it means dragging in a few more dependencies. For most people, pcsc-lite+ccid is how they are going to access their smart card readers and if you are complaining about the distro package supporting pcsc-lite ... sorry dude, not going to take that one out. On 03/12/2011 04:09 PM, Kalev Lember wrote: Unfortunately, I believe your use case is even less supported nowadays. Since the 0.12.0 release, opensc no longer supports building in both pcsc-lite and openct support, so starting with Fedora 15, the opensc package is built with only pcsc-lite support. By the way, openSUSE 11.4 was released a few days ago and they are also shipping opensc 0.12.0. I just checked how they are building it and they've also taken out openct support and building opensc only with pcsc-lite. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Gnome smartcard manager
On 03/12/2011 03:19 PM, Mr Dash Four wrote: I had to recompile the whole OpenSC/OpenCT framework from source as the one shipped with Fedora was utter crap (and I mean *really* crap)! I also had to upgrade gdm to 2.32 (again, compiled from source) in order to get it to work with the rest of the framework in FC13. Can you elaborate more? From your previous mails to the ML I understood that you were building a custom initrd with opensc and didn't want pcsc-lite dragged in. To avoid having to bundle all the extra libraries in the initrd, you then rebuilt opensc with only openct support. How does that make the distribution package utter crap, as you put it? Unfortunately, I believe your use case is even less supported nowadays. Since the 0.12.0 release, opensc no longer supports building in both pcsc-lite and openct support, so starting with Fedora 15, the opensc package is built with only pcsc-lite support. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] New 0.12.1 release?
Hello, Two different people have recently asked on the ML about new opensc bug fix release. I would additionally like to add a third patch I'd like to see included in the release: r5112 EstonianEid: add new 2011 card ATR (18.01.2011+) Thanks, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo
On 01/11/2011 06:21 PM, Mr Dash Four wrote: Something like that might actually warrant a new point release of opensc to make sure Linux distros pick up the fix. Having a point release for every single bug fix would be overkill. So the question is, what's the best approach to quickly distribute important fixes? What would fit the workflow of the package maintainers? Any suggestions? May be distribute a patch with the fix directly with the various distributors and make a 'dash' release (i.e. 12.0-2) - at least that is how it works, I think, with FC. Putting my Fedora packager hat on, please release new tarballs if you have important bugfixes to distribute. This ensures everybody is using the same code and makes problems much easier to debug. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo
On 01/11/2011 03:28 PM, Aventra development wrote: Hi, Thank you very much! This fixed the problem, could it be committed to the trunk? Too bad the release was already done, but when is the next one, so that this fix could be included. Getting this to the Linux distributions would be even more important. Something like that might actually warrant a new point release of opensc to make sure Linux distros pick up the fix. Regards, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fwd: OpenSC 0.12.0 released
On 12/23/2010 09:09 AM, Martin Paljak wrote: OpenSC 0.12.0 is ready. Thanks for the release. I just updated OpenSC package in Fedora Rawhide to 0.12.0. Rawhide is the name of the development repository which gets released as Fedora 15 in May. -- Regards, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] win32: path to OpenSC windows registers
On 12/07/2010 10:43 AM, Viktor TARASOV wrote: The Gemalto and Oberthur (in the recent versions) middlewares install their DLLs into the 'Program Files'. My hidden motivation to do the same for the OpenSC MSI is that I do not managed to build the MSI that un-installs the DLLs installed in system32. The update and un-update of the PATH variable works remarkably good. Victor, that's a very good idea to use standard MSI generated with WiX! Instead of adding 'Program Files\OpenSC' directory to PATH, it might be better to put all the deps (libopensc.dll, zlib.dll, iconv.dll, etc) into WinSxS [1] and only put the pkcs11 libraries in 'Program Files\OpenSC'. Polluting global DLL namespace (either by putting DLLs in Windows\System32 or adding DLL files to PATH) makes it very hard for other packages to ship DLL files with the same names. [1] http://en.wikipedia.org/wiki/Side-by-side_assembly Hope this helps, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4930] add to r4904: fix calculating of signature size for CKK_GOSTR3410
On 12/09/2010 11:40 AM, Martin Paljak wrote: Hello, On Dec 9, 2010, at 9:23 AM, webmas...@opensc-project.org wrote: Revision: 4930 Author: s Date: 2010-12-09 07:23:10 + (Thu, 09 Dec 2010) Log Message: --- add to r4904: fix calculating of signature size for CKK_GOSTR3410 -*pLength *= 2; +*pLength = (*pLength + 7) / 8 * 2; Could you also add a comment? Why not (*pLength + 7) / 4? Replying instead of the commit's author. (length + 7) / 8 is a common way to calculate stride width so that the result is aligned to 8. It might be a good idea to give a meaningful name to 2, but please don't simplify the calculation by replacing / 8 * 2 with 4 as it would make it harder to understand. Regards, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] llibopensc.pc is not installed
On 12/07/2010 05:21 PM, Frank Morgner wrote: Hi! You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, thus the .pc file is removed. Why is it not encouraged? Why do you need libopensc.pc (or what is linking agains libopensc)? I am using smart card abstraction offered by libopensc. For what it's worth, we were also considering using libopensc for smart card abstraction, but in the end chose another library because the public interface to libopensc was removed in svn. Also, Martin's opensc tokend uses libopensc directly, which makes it very painful to build. Instead of building against the public headers, the tokend needs whole opensc source tree for building. Regards, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 0.12.0 release date and windows installer
On 12/06/2010 01:25 PM, Martin Paljak wrote: Hello, On Dec 6, 2010, at 12:37 PM, Johannes Becker wrote: Am Donnerstag 02 Dezember 2010 schrieb Martin Paljak: Have you decided on a release date yet for 0.12.0? Either today or tomorrow. I didn't find any newer versions in the wiki. The Fedora compilation (which does not have EC support in OpenSSL) git fixed on the weekend, so the release can happen. Could you please do another public release candidate before rolling out the final release tarballs? Thanks, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] [PATCH] fix buffer overflow in pkcs15-itacns.c
gcc warns about a potential buffer overflow: In file included from /usr/include/string.h:642:0, from pkcs15-itacns.c:38: In function 'strncat', inlined from 'itacns_add_keyset.clone.3' at pkcs15-itacns.c:540:9: /usr/include/bits/string3.h:154:3: warning: call to __builtin___strncat_chk might overflow destination buffer In function 'strncat', inlined from 'itacns_add_keyset.clone.3' at pkcs15-itacns.c:552:9: /usr/include/bits/string3.h:154:3: warning: call to __builtin___strncat_chk might overflow destination buffer And fair enough, strncat(3) also says: If src contains n or more characters, strncat() writes n+1 characters to dest (n from src plus the terminating null byte). Therefore, the size of dest must be at least strlen(dest)+n+1. The attached patch builds, but otherwise is untested. -- Kalev Index: src/libopensc/pkcs15-itacns.c === --- src/libopensc/pkcs15-itacns.c (revision 4631) +++ src/libopensc/pkcs15-itacns.c (working copy) @@ -549,7 +549,7 @@ Could not add PIN); strncpy(pinlabel, PUK , sizeof(pinlabel)); - strncat(pinlabel, label, sizeof(pinlabel)); + strncat(pinlabel, label, sizeof(pinlabel)-strlen(pinlabel)-1); /* * Looking at pkcs15-tcos.c and pkcs15-framework.c, it seems that the * right thing to do here is to define a PUK as a SO PIN. Can anybody ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Aladdin eToken Pro w/PKCS15 (was Re: OpenPGP card v2)
On 07/14/2010 06:15 PM, David Woodhouse wrote: ccid-1.3.11-1.fc13.x86_64 opensc-0.11.13-2.fc14.x86_64 pcsc-lite-1.6.1-4.fc14.x86_64 Looks like you have installed pcsc-lite from rawhide on your F-13 machine, but the ccid package is still the old one. Try updating ccid too and see if it starts working better. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new versions
On 06/06/2010 11:17 PM, Aleksey Samsonov wrote: Hello, Aleksey Samsonov wrote: martin, do you want to create new releases? Need to test 0.11 branch with the openssl engine fix. Could you wait a few days? I'm try to find more clean solution. We have problem under the stipulation that load gost engine before loading engine_pkcs11 (which loading gost engine). I fixed to trunk and backported to releases/opensc-0.11.14. Thanks! Are there any plans to release opensc 0.11.14 now? How about making a tarball 0.12 beta release from trunk too? -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How do we know that a card is locked and needs unblocking using PUK?
On 07/01/2010 01:28 PM, Martin Paljak wrote: for a PIN or if PIN verification fails with CKR_PIN_LOCKED (which is SC_ERROR_AUTH_METHOD_BLOCKED in libopensc). If triest left is implemented by the driver and available, CKF_USER_PIN_LOCKED token flag can also be used to detect a locked PIN via PKCS#11. I have a patch to expose this in libp11. However, I'm not sure if changing a struct like that breaks ABI or not. If we need to break ABI anyway, it might make sense to reorder the new flags in a more natural order, instead of putting them all before token-_private = tpriv; in the struct. -- Kalev -- Index: libp11/src/p11_slot.c === --- libp11/src/p11_slot.c (revision 192) +++ libp11/src/p11_slot.c (working copy) @@ -387,6 +387,9 @@ token-secureLogin = (info.flags CKF_PROTECTED_AUTHENTICATION_PATH) ? 1 : 0; token-userPinSet = (info.flags CKF_USER_PIN_INITIALIZED) ? 1 : 0; token-readOnly = (info.flags CKF_WRITE_PROTECTED) ? 1 : 0; + token-userPinCountLow = (info.flags CKF_USER_PIN_COUNT_LOW) ? 1 : 0; + token-userPinFinalTry = (info.flags CKF_USER_PIN_FINAL_TRY) ? 1 : 0; + token-userPinLocked = (info.flags CKF_USER_PIN_LOCKED) ? 1 : 0; token-_private = tpriv; return 0; Index: libp11/src/libp11.h === --- libp11/src/libp11.h (revision 192) +++ libp11/src/libp11.h (working copy) @@ -80,6 +80,9 @@ unsigned char secureLogin; unsigned char userPinSet; unsigned char readOnly; + unsigned char userPinCountLow; + unsigned char userPinFinalTry; + unsigned char userPinLocked; void *_private; } PKCS11_TOKEN; ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How do we know that a card is locked and needs unblocking using PUK?
On 07/01/2010 02:53 PM, Martin Paljak wrote: I don't see why would it be bad to expose the token info flags field itself. It might be fine. What my patch does is expose new flags _in the same manner as existing flags are exposed_; if you want to rework the libp11 API to give direct access to token info flags field, that's a different story. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How do we know that a card is locked and needs unblocking using PUK?
On 07/01/2010 03:14 PM, Kalev Lember wrote: On 07/01/2010 02:53 PM, Martin Paljak wrote: I don't see why would it be bad to expose the token info flags field itself. It might be fine. What my patch does is expose new flags _in the same manner as existing flags are exposed_; if you want to rework the libp11 API to give direct access to token info flags field, that's a different story. I clicked send too fast. What I wanted to say in addition is that it looks very much that the person who originally developed the API tried to avoid exposing the token info flags field. Instead he chose to expose all flags separately. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new versions
On 05/26/2010 11:21 PM, Andreas Jellinghaus wrote: * what happend to opensc 0.11.*? I thought the problem with gost / engine_pkcs11 is so big, it should be fixed in the 0.11 line to help normal users, and so distributions can backport that fix if they want. * is it time for a release candidate or pre-patch in trunk? i.e. are there any further plans that will change API/ABI or is API/ABI stable now again? What API/ABI stability are you talking about? libopensc no longer installs any public headers, which effectively prevents any other application from directly linking against it. I was under the impression that this change was done so that people wouldn't have to worry about libopensc API stability: libopensc would only be used internally in opensc and thus could be changed at will, as long as every API user _inside_ opensc gets fixed up. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] wget and pkcs11?
On 04/21/2010 10:01 PM, Jim Rees wrote: I'm in need of a command line utility that can do https fetches given a url, like wget, but use pkcs11 for the crypto ops, so I can store the client cert/key on a smart card. Firefox will do this but it's overkill and I need something scriptable. Any suggestions? I have not actually tried it, but perhaps curl can use pkcs11 if libcurl is compiled against NSS. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changes to opensc-project(.org) (Re: opensc-commit spam)
On 03/24/2010 10:09 PM, Ludovic Rousseau wrote: 2010/3/24 Martin Paljakmar...@paljak.pri.ee: I'd like to change the main page of opensc-project.org with what can be seen on http://www.opensc-project.org/opensc in near future, what do you think? I like this idea. Looks good. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Windows installer
On 03/25/2010 09:26 AM, Martin Paljak wrote: On Mar 24, 2010, at 21:55 , Alon Bar-Lev wrote: I just provide them because after I rewrote the opensc build system, there was no reason to maintain parallel build system for windows only, and the windows build was unmaintained anyway. Right, the problem here being that there has never been no windows build system. It has always only been possible to build the code with visual studio. That's OK, as long as we can provide working binaries. One option would be to have an alternative build system for native build, like CMake (in addition to the autotools stack). I remember somebody showing interest in providing a cmake build solution as well. I think it would be a pretty good idea to replace the current native Windows build system (nmake) with something like CMake: 1) Current nmake build files are partially generated by autotools, so it's not possible to build opensc on Windows without first bootstrapping it with autotools. 2) OpenSC nmake build files are unmaintained. This is not really a surprise: nmake is Windows-only, and as most of the opensc developers are Linux/Mac users, they have no way of testing any changes to nmake build files. Usually someone updates the files blindly, without having any idea if they really work. 3) I'd say that most Windows developers prefer to use Visual Studio for both editing code and building it, but having nmake build files (mostly meant for being invoked on command line) doesn't make their life any easier. 4) Current nmake build files don't support building for 64 bit Windows (there's no official 64 bit Firefox release, so it's not much of a problem right now for most of the users). 5) One HAS to edit the build files in order to use the nmake build. See my sed command which I use to configure opensc at the end of this mail. Having to do something like that is not user friendly. CMake is a cross-platform tool for first configuring a project and then generating native build files. It can generate GNU Makefiles, nmake makefiles, Visual Studio projects, XCode projects, and more. I think it would be a pretty good idea to replace the unmaintained nmake build files with CMake. If it's done properly, people could easily test their build system changes on Linux, and it would automagically also work on Windows. If nobody else steps up, I could try to write some cmake build files. This is how I configure opensc build on Windows currently: mv win32\Make.rules.mak win32\Make.rules.mak.orig sed win32\Make.rules.mak.orig win32\Make.rules.mak \ -e s|^LIBLTDL_INCL.*|LIBLTDL_INCL = /I$(LIBLTDL_INC)| \ -e s|^LIBLTDL_LIB.*|LIBLTDL_LIB = $(LIBLTDL_LIB)| \ -e s|^OPENSSL_INCL_DIR.*|OPENSSL_INCL_DIR = /I$(OPENSSL_STATIC_INC)| \ -e s|^OPENSSL_LIB.*|OPENSSL_LIB = $(OPENSSL_STATIC_LIB) user32.lib advapi32.lib| \ -e s|^#OPENSSL_DEF|OPENSSL_DEF| \ -e s|^#ZLIB_DEF|ZLIB_DEF| \ -e s|^ZLIB_INCL_DIR.*|ZLIB_INCL_DIR = /I$(ZLIB_INC)| \ -e s|^ZLIB_LIB.*|ZLIB_LIB = $(ZLIB_LIB)| \ -e s|^ICONV_INCL_DIR.*|ICONV_INCL_DIR = /I$(LIBICONV_INC)| \ -e s|^ICONV_LIB.*|ICONV_LIB = $(LIBICONV_LIB)| \ -e s|^#ICONV_DEF|ICONV_DEF| \ -e s|/MACHINE:IX86|$(MACHINE)| @for %f in ( src/scconf/Makefile.mak src/pkcs11/Makefile.mak src/common/Makefile.mak ) do \ mv %f %f.orig \ sed %f.orig %f \ -e s|/machine:ix86|$(MACHINE)| -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changes to opensc-project(.org)
On 03/10/2010 01:52 PM, Martin Paljak wrote: On Mar 10, 2010, at 12:28 , Andreas Jellinghaus wrote: so what is your plan for the other project? I still think each project needs to have some minimal user/developer documentation shipped with them in the tar.gz, so it is available in the distributions. do you agree? how should that documentation be written and maintained, if you implement your plan with the new trac/wiki? I proposed docbook (or some other format) with source code of the documentation inside the svn, but I don't remember you commenting on that. User documentation in the package should be 1. README file 2. man pages. Evertyhing else should be online. Developer documentation, if any, should be a doxygen API description. A versioned README/INSTALL file is the easiest in many cases. Guides, tutorials, howtos are best left to the web. I also think that static wiki pages in release tarballs don't make much sense. I always go to the project's web page and look up info from there. By all means, if you need to rip out all the static wiki pages from release tarballs to better structure the web page, go for it. They don't really add much value. Release tarballs need the following documentation: - man pages - License file (COPYING) - File with instructions how to compile the code what you need to compile it (README) - NEWS/ChangeLog -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changes to opensc-project(.org)
On 03/09/2010 11:37 PM, Andreas Jellinghaus wrote: Am Dienstag 09 März 2010 14:58:41 schrieb Martin Paljak: One option, as said, was direct people to opensc-devel from some time onwards. OpenSC et al don't have such a huge userbase and a solid development/user separation that the artificial separation between two lists would do any good. The goal would be to guide traffic to the most viable list. not sure how many discussions on -devel are interesting for pure users. I think combining both mailing lists into one would be a good idea. It should reduce confusion which list to use (-devel or -users) for sending mail and more people would see patches flying by. Even if people from -users list wouldn't start contributing to opensc right away, this might attract some new developers. Also, both mailing lists are rather low volume right now. OpenSC is a library for other developers to use, and the same goes for other projects hosted under opensc-project.org. OpenSC isn't something that true end users like Aunt Bessie and Uncle Bob would knowingly use. OpenSC users are almost always also developers (yes, maybe not _opensc_ developers, but developers nonetheless). I think it would only help opensc cause if all these people read the combined list. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] move to dist-xz format / use .tar.xz instead of.tar.gz
On 02/16/2010 11:05 AM, Ralf Schlatterbeck wrote: On Tue, Feb 16, 2010 at 09:02:29AM +0100, Andreas Jellinghaus wrote: distributions like slackware and fedora moved to the xz compression a while ago, even the kernel developers think about abandoning the .tar.gz file format in favor of alternatives with better compression like .tar.bz2 or .tar.xz (or short: .txz). snip Does it really matter if the distribution is 1M or 1.5M? I can see this makes a difference for large distributions like the kernel, though. So I vote for keeping .tar.gz -- or if size really matters move to bz2. An option would be to have the same tarball compressed with both gzip and xz, and distribute both of them side-by-side. That way both parties should be happy: new distributions who want to use best compression technology can get tar.xz, and people who want to install new opensc on older distributions can still keep using tar.gz. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On 02/09/2010 09:04 AM, François Leblanc wrote: Concerning your fixup, I remember you that mingw32 seems not to have winscard.h it's why I've make a complex cardmod.h detection since if you don't have winscard.h you use internal-winscard.h I think the _right_ way in long term would be to clean up internal-winscard.h and submit it for upstream mingw32 inclusion as winscard.h. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.11 released today
On 11/01/2009 01:16 PM, Ludovic Rousseau wrote:
2009/10/29 Hannu Kotipaloha...@kotipalo.fi:
Same in Ubuntu 9.10 (64 bit). There seems to be a missing symbolic link.
This helped me:
sudo ln -s /lib/libpcsclite.so.1.0.0 /usr/lib/libpcsclite.so.1
On Ubuntu libpcsclite is in /lib and not in /usr/lib.
See http://bugs.debian.org/531592
The Ubuntu opensc package should be patched to use a different path.
I think the correct fix here would be in configure.ac:
-DEFAULT_PCSC_PROVIDER=/usr/lib${libdir##*/lib}/libpcsclite.so.1
+DEFAULT_PCSC_PROVIDER=libpcsclite.so.1
One shouldn't make assumptions in what directory libpcsclite.so.1 is
installed.
If distributions want to hardcode a path, they can do it. But opensc's
default should be something that works across most distributions.
--
Kalev Lember
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.11 released today
On 11/01/2009 04:43 PM, Andreas Jellinghaus wrote:
Am Sonntag 01 November 2009 13:06:49 schrieb Peter Stuge:
Kalev Lember wrote:
I think the correct fix here would be in configure.ac:
-DEFAULT_PCSC_PROVIDER=/usr/lib${libdir##*/lib}/libpcsclite.so.1
+DEFAULT_PCSC_PROVIDER=libpcsclite.so.1
One shouldn't make assumptions in what directory libpcsclite.so.1 is
installed.
I agree, -rpath is horrible.
but this discussion isn't about rpath. we are leading the shared
library as plugin.
Yes, it's not rpath here but rather telling dlopen() where exactly the
lib is located. But in any case if we don't specify a path, dlopen()
will search for libpcsclite.so.1 in default lib directories (usually
/lib and /usr/lib in that order). I don't think it'd make sense to
hardcode a path in here, but rather rely on dlopen()'s behaviour to find
the right lib. I'd change the default provider to libpcsclite.so.1
(without path).
well, maybe we shouldn't or at least by default not do that.
alon was working on an alternative implementation and thus
made it easy to configure, which library for the same
static interface is loaded. while this is real nice for developers,
it creates confusion for normal users without this need.
I don't want to create a new 0.11 release, as editing a config
file or using different configure options is easy. but what is
the best suggestion for distributions?
Well, opensc's default currently does not matter much for distributions,
because most of them are already specifying pcsc provider through
configure options (opensc's old default didn't work at all).
In long term, however, the change might do good. Fedora already switched
to libpcsclite.so.1 without path as default provider [1]. If we
changed opensc's default to use no path, it'd make life easier for
Debian and Ubuntu packages too. In Debian and Ubuntu libpcsclite gets
installed in different directories, which means that their opensc
packaging also differes. With us changing the default to a sane value,
those two distros might be able to merge their opensc packaging differences.
[1]
http://cvs.fedoraproject.org/viewvc/rpms/opensc/devel/opensc.spec?r1=1.49r2=1.50
--
Kalev Lember
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.11 -rc1 release candidate available
On 10/23/2009 04:39 PM, Andreas Jellinghaus wrote: Please give it a final test. http://www.opensc-project.org/files/opensc/testing/opensc-0.11.11-rc1.tar.gz Doesn't seem to compile with openssl-1.0 beta3 (distributed with Fedora 12, for example): /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/pkcs15init -I../../src/include -pthread -fno-strict-aliasing -g -O2 -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c -o openssl.lo openssl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/pkcs15init -I../../src/include -pthread -fno-strict-aliasing -g -O2 -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c openssl.c -fPIC -DPIC -o .libs/openssl.o openssl.c:17:24: error: openssl/ec.h: No such file or directory openssl.c: In function ‘sc_pkcs11_openssl_md_final’: openssl.c:169: warning: passing argument 3 of ‘EVP_DigestFinal’ from incompatible pointer type /usr/include/openssl/evp.h:514: note: expected ‘unsigned int *’ but argument is of type ‘CK_ULONG *’ openssl.c: In function ‘gostr3410_verify_data’: openssl.c:272: error: ‘EC_POINT’ undeclared (first use in this function) openssl.c:272: error: (Each undeclared identifier is reported only once openssl.c:272: error: for each function it appears in.) openssl.c:272: error: ‘P’ undeclared (first use in this function) openssl.c:274: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token openssl.c:274: error: ‘group’ undeclared (first use in this function) make[3]: *** [openssl.lo] Error 1 make[3]: Leaving directory `/home/kalev/cvs/mingw32-opensc/devel/native/opensc-0.11.11-rc1/src/pkcs11' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kalev/cvs/mingw32-opensc/devel/native/opensc-0.11.11-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kalev/cvs/mingw32-opensc/devel/native/opensc-0.11.11-rc1' make: *** [all] Error 2 -- Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] trunk and 0.12 branch
On 10/23/2009 04:42 PM, Andreas Jellinghaus wrote: snip So what will be the best way to start 0.12 development in /trunk/? a) merge all changes from 0.12 branch into trunk? (how to do that? as one big change, or as a series of commits?) b) svn rm /trunk/; svn mv /branches/martin/0.12 /trunk ? Option a) is probably better, because then the development history in trunk is preserved. Martin used to do his development in git. If that's still the case, it might be possible to rebase his work on top of the new changes in trunk and then merge it to svn as a series of commits. -- Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.11 -rc1 release candidate available
On 10/23/2009 06:10 PM, Aktiv Co. Aleksey Samsonov wrote: openssl/opensslconf.h - #define OPENSSL_NO_EC Right? It is my bug. Thanks! Yes, OPENSSL_NO_EC is defined in there. Thanks for taking a look. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.11 -rc1 release candidate available
On 10/23/2009 09:26 PM, Aleksey Samsonov wrote: Kalev Lember wrote: On 10/23/2009 06:10 PM, Aktiv Co. Aleksey Samsonov wrote: openssl/opensslconf.h - #define OPENSSL_NO_EC Right? It is my bug. Thanks! Yes, OPENSSL_NO_EC is defined in there. Thanks for taking a look. Thanks! Fix committed to trunk. Thanks Aleksey, builds fine now. -- Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Opensc minidriver for base csp.
On 10/12/2009 09:45 AM, François Leblanc wrote: * we need to check copyright situation with the cardmod.h file and maybe you used some template or similar for the ccm? then we need to give proper reference etc. a few other files need a copyright header too. Yes absolutely. The cardmod.h copyright need some attention. For opensccm prototypes come from the cardmod.h. cardmod.h is part of Microsoft CNG SDK [1]. I suppose instead of redistributing the header, it would be better to require that the CNG SDK msi is installed at the build machines. I haven't investigated the header's copyright, but I doubt it has a free license. However, removing the header also has a drawback: it makes cross compiling with mingw harder. [1] http://www.microsoft.com/downloads/details.aspx?FamilyId=1EF399E9-B018-49DB-A98B-0CED7CB8FF6Fdisplaylang=en -- Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.10-pre1 preview for testing
On 10/09/2009 12:29 PM, Andreas Jellinghaus wrote: I made a preview in case we forgot something important. if you find some time, please test and report back. thanks! http://www.opensc-project.org/files/opensc/testing/opensc-0.11.10-pre1.tar.gz Hi, Windows nmake + msvc build looks broken: cl /D_CRT_SECURE_NO_DEPRECATE /Zi /MD /nologo /DHAVE_CONFIG_H /I..\..\src\include /I..\..\sr c\include\opensc /I..\..\src\common /IC:/build/Win32/openssl-static/include /IC:/build/Win32/zlib123 /IC:/build/Win32/libltdl /IC:/build/Win32/libiconv-1.11.1/include /D_WIN32_WINNT=0x0400 /DWIN32_LEA N_AND_MEAN /DENABLE_OPENSSL /DENABLE_ZLIB /DENABLE_ICONV /DOPENSC_FEATURES=\pcsc openssl zlib icon v\ /c scconf.c parse.c write.c sclex.c scconf.c parse.c write.c sclex.c Generating Code... lib /nologo /MACHINE:ix86 /out:scconf.lib scconf.obj parse.obj write.obj sclex.obj NMAKE : fatal error U1073: don't know how to make 'crc_AetB.obj' Stop. -- Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] pkcs11-helper license text wording
Hello, I'm packaging pkcs11-helper for Fedora [1] and during the new package review process Jason Tibbitts noticed a problem with the BSD license text wording. The string ORGANIZATION appears unmodified in every source file, rendering the third, advertising clause essentially void. You are supposed to replace ORGANIZATION with either your name or the name of the organization. Without doing that you might just as well use the 2-clause BSD or the MIT license. [1] https://bugzilla.redhat.com/show_bug.cgi?id=510729 -- Regards, Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] Fix onepin-opensc-pkcs11.dll manifest
Kalev Lember wrote: Hello, The attached patch fixes onepin-opensc-pkcs11.dll manifest embedding with Microsoft compilers. Sorry for replying to myself, but could someone please apply this one-liner? Without this patch manifest doesn't get embedded in onepin dll, and because of that the dynamic linker isn't able to locate Visual C++ runtime libraries in WinSxS. -- Thanks, Kalev Lember --- opensc-upstream/src/pkcs11/Makefile.mak.orig2009-05-30 16:04:49.571618509 +0300 +++ opensc-upstream/src/pkcs11/Makefile.mak 2009-05-30 16:05:16.754025211 +0300 @@ -25,7 +25,7 @@ echo EXPORTS $*.def type opensc-pkcs11.exports $*.def link $(LINKFLAGS) /dll /def:$*.def /implib:$*.lib /out:$(TARGET0) $(OBJECTS) hack-enabled.obj ..\libopensc\opensc.lib ..\scconf\scconf.lib ..\pkcs15init\pkcs15init.lib ..\common\common.lib winscard.lib $(OPENSSL_LIB) $(LIBLTDL) gdi32.lib - if EXIST $(TARGET).manifest mt -manifest $(TARGET).manifest -outputresource:$(TARGET);2 + if EXIST $(TARGET0).manifest mt -manifest $(TARGET0).manifest -outputresource:$(TARGET0);2 $(TARGET): $(OBJECTS) hack-disabled.obj ..\libopensc\opensc.lib ..\scconf\scconf.lib ..\pkcs15init\pkcs15init.lib ..\common\common.lib echo LIBRARY $* $*.def ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] [libp11] [PATCH] add missing MSVC build files to make dist target
Hello, libp11-0.2.5.tar.gz doesn't ship with Makefile.mak and winconfig.h files that are needed for building with MSVC. Those files are, however, present in SVN. The attached patch adds those two files to the make dist target, so that they'd get included in next release tarball. -- Kalev Lember Index: libp11/Makefile.am === --- libp11/Makefile.am (revision 182) +++ libp11/Makefile.am (working copy) @@ -12,7 +12,7 @@ $(srcdir)/m4/ltversion.m4 $(srcdir)/m4/lt~obsolete.m4 \ $(srcdir)/m4/ltoptions.m4 \ $(srcdir)/packaged -EXTRA_DIST = svnignore +EXTRA_DIST = svnignore Makefile.mak winconfig.h dist_noinst_DATA = COPYING bootstrap \ $(srcdir)/examples/Makefile $(srcdir)/examples/*.c $(srcdir)/examples/README ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Cygwin? Mingw? --with-cygwin-native
Hello, Fedora has a very promising MinGW cross compiling project where they provide MinGW Windows cross compiler and a large amount of precompiled libraries. See: https://fedoraproject.org/wiki/MinGW I've packaged libp11 and opensc for this project, so if you are running Fedora 10 you can easily download them and all their dependencies with yum by running: yum install mingw32-libp11 mingw32-opensc Right now mingw32-opensc is still in updates-testing repository, so you might need to enable it first. But in a week or so it will hit stable updates repo too. -- Best regards, Kalev Lember ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] [PATCH] opensc: fix GNU libiconv detection
Hello, The attached patch fixes GNU libiconv detection by adding an additional libiconv symbol check to autoconf -liconv link test. Right now some iconv implementations have only iconv* symbols (GNU libc), some have only libiconv* (GNU libiconv), and some have both defined (Mac OS X's iconv), so it's necessary to check for both variants. Without this patch configure fails to properly detect GNU libiconv. -- Best regards, Kalev Lember diff -up opensc-0.11.7/configure.ac.iconv opensc-0.11.7/configure.ac --- opensc-0.11.7/configure.ac.iconv2009-04-21 17:20:59.0 +0300 +++ opensc-0.11.7/configure.ac 2009-04-21 17:30:47.0 +0300 @@ -464,6 +464,16 @@ else [ ac_cv_lib_iconv=yes ICONV_LIBS=-liconv + ], + [ + AC_CHECK_LIB( + [iconv], + [libiconv], + [ + ac_cv_lib_iconv=yes + ICONV_LIBS=-liconv + ] + ) ] ) ] ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
