[opensc-devel] move to dist-xz format / use .tar.xz instead of.tar.gz
Hi, 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). if we want to try doing something like that too, opensc 0.12 would be a good time. for reference, I checked current trunk with all options: sizefile name / format 2416782 opensc-0.12.0-svn.shar.gz 1135736 opensc-0.12.0-svn.tar.bz2 1519708 opensc-0.12.0-svn.tar.gz 1009746 opensc-0.12.0-svn.tar.lzma 1009948 opensc-0.12.0-svn.tar.xz 2508011 opensc-0.12.0-svn.tar.Z 1922452 opensc-0.12.0-svn.zip uncompression time: opensc-0.12.0-svn.shar.gz real0m10.836s user0m3.760s sys 0m7.120s opensc-0.12.0-svn.tar.bz2 real0m0.328s user0m0.280s sys 0m0.040s opensc-0.12.0-svn.tar.gz real0m0.116s user0m0.030s sys 0m0.030s opensc-0.12.0-svn.tar.lzma real0m0.156s user0m0.120s sys 0m0.090s opensc-0.12.0-svn.tar.xz real0m0.173s user0m0.070s sys 0m0.120s opensc-0.12.0-svn.tar.Zreal0m0.119s user0m0.030s sys 0m0.080s opensc-0.12.0-svn.zip real0m0.416s user0m0.150s sys 0m0.070s so tar.xz would be 50% smaller than tar.gz, but still uncompress quite fast. compression of xz files is of course much slower than gzip (about factor 20), and uses a lot of memory, but that only affects people creating new tar.xz files. most linux distributions have xz-utils installed or available in their repository, so users would need to do nothing / simply install those. command line: tar xf file works on all formats - tar, tar.gz, tar.xz etc, so simply drop the z option when extracting, and tar will figure out which compression format the file has and how to decompress it. for reference, the packaging option is j for bzip2 and J for xz I think. AM_AUTOMAKE_INIT takes options like dist-bzip2 or dist-xz and will then generate those matching files. windows users can continue to use the free 7-zip to extract tar.gz files, but for tar.xz they need to use the 9.00 version (currently in beta test), the old 4.* version won't work. in summary: I'm not sure at all, if it is worth the trouble to switch from tar.gz to some better compression. we don't have many people downloading files, no bandwidth issues or anything like that. on the other hand distributions are happy to save disk space etc. if source packages are using a better compression mechanism. I reviewed latest trends, what other people do and so on, and I believe if we want to swich to a different compression, then tar.xz is the current recommendation. it is new, and not everyone has those tools for it installed, but already enough people use it so it won't be a big pain. what do you think? keep tar.gz? switch to tar.xz? something else? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc-pkcs11.so displaying certs differently?since opensc 0.11.10?
Found some time to look at this again, was working with opensc 0.11.9 last days in my setup here. On Thu, Feb 04, 2010 at 11:23:20AM +0100, Andreas Jellinghaus wrote: Am Donnerstag 04 Februar 2010 10:20:37 schrieb Christian Horn: Also the nonworking opensc-rev hands out my personalized cert when asking for id 46 with pkcs15-tool -r 46|openssl x509 -noout -subject you have two certificates with id 46. which one is presented to you? The one with my name in the subject, so the personalized one. or are two certificates shown with old opensc? Output of 'pkcs15-tool -c' is the same with working/nonworking opensc. does opensc-tool -f show the content of all files, including the certificates (file id in the pkcs15-tool --dump). Yes, shows both df0143b1 (the cert i want) and df01c200 (the cert that is now handed out by strongswan). or can you try downloading those certificate files with opensc-explorer? (cd to the directory (first 4 bytes), then get the file (the next four bytes of the pathname)). (cd 3f00 gets you to the main folder / top directory...) I can get both certs that way, and bot working/nonworking opensc give me the same contents. first I guess strongswan wants to authenticate to the remote. Yes. why does it try to use a CKA_ID 46 cert which is for encryption? strange. but maybe that certificate was placed on the remote site for some reason. certid 46 is what i configured, its what i need to authenticate with. The remote site apparently also checks the subject of the cert that is used. This is a personoalization-procedure done for the cards here. so your software for some reason created two certs with the same ID and now opensc need to sort out the mess :) Yes, at a time in the past also pkcs15-tool did hand out the other cert. By that time we patched opensc, later the code here was changed to the other cert was handed out - and this is still the behaviour of pkcs15-tool: pkcs15-tool -r 46 hands me out the cert i really want, the personalized one. Correct sig of the wrong cert i suspect.. well, signatures are created with rsa keys, not certificates. and there is only one rsa key with ID 45, so it has to be the right one. I think the cert is also checked on the remote side of the vpn-connection here. can your somehow find all certificates, find out which is the right one, and which is the wrong one, and check if strongswan delivers the right or wrong file to the other side? maybe it shows the old certificate and then gets a signature with the RSA key (which is meant for the new certificate)? Doing 'ipsec listcards' in strongswan gives me different results with working/nonworking opensc: working one shows my name in subject, nonworking one shows subject: 'C=DE, ND=1, CN=NKS 08 A 78205', both for id 46. oh, and does the remote strongswan site show any errors that might show what is going on? again, I think it might be a strongswan issue... Some proprietary stuff on the other side, hard to reach responsable people there for debugging.. btw: does the old and new ID 46 certificate contain the same rsa public key or do they differ? this would be interesting to know, if you can get to those files somehow. No clue how to see this, just see 'id 46' as the link to what rsa-key is to be used - and thats id 46 for both certs. In the beginning also 'pkcs15-tool' spit out the other cert, we started to fix this with internal patches, later it was properly fixed in opensc-code. so worst case you can dig out an old version of opensc, to see what the old certificates are about? I dont know what you mean by that. I noticed editing the paths to the certs in pkcs15-tcos.c doesnt help me this time as it did in the really old time bevore opensc was modified to hand out the personalized cert when id 46 is requested. this whole situation with two certificates with the same ID confuses me a lot. maybe it is simple and some flag is used to disable the old ones, but I'm no expert here (and the asn.1 debugging code doesn't show values, so even if I knew what to look for, it wouldn't be in the log). Would rather guess that the windows-software here is just coded in such a way to deal with this. Its also using a 'global pin' for everything instead of local ones. so maybe peter or pierre can help. other than that, I think it might be a strongswan issue. or at least getting the error from strongswan could help, So any other ideas how pkcs11 could again perform with the old behaviour? btw: you could extract the value to be signed and the signed data from the log file, transform them to binary, and check with your certificate (the one you can extract, or both), if that is a valid signature for the public key in the cert (IIRC openssl command line tools can extract it and/or use the cert or pubkey for signature validation). Thanks for the idea.. guess if noone else here has an idea i will approach strongswan
Re: [opensc-devel] move to dist-xz format / use .tar.xz instead of.tar.gz
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). I've never heard of xz before your post (not that I claim to be up to date with current developments in compression technology). And debian stable (aka lenny) doesn't have it: % apt-cache search xz makexvpics - updates .xvpics thumbnails from the command line xzgv - Picture viewer for X with a thumbnail-based selector xzip - Interpreter of Infocom-format story-files xzoom - magnify part of X display, with real-time updates zblast-x11 - X11 version of zblast, shoot 'em up space game horae-examples - ATHENA and ARTEMIS examples and tutorials or is this in a package with an obscure name? And debian stable tar doesn't have a -J option. (And you don't think the unsecure .shar format is a canditate?) 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. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131www: http://www.runtux.com A-3411 Weidling email: off...@runtux.com osAlliance member email: r...@osalliance.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc-pkcs11.so displaying certs differently?since opensc 0.11.10?
I haven't re-read all log files and emails. but this is my general impression as summary: * your card is strange, as several certificates have the same ID. * I guess the problem is: the old certificate was not deleted or hidden or whatever, so opensc has no reason to not show it. * now the application sees several certificates and delivers the wrong one to remote, thus authentication breaks. so the solution is easy: change the app to not filter the right certificate with the CKA_ID == 46 filter, which finds two certs, instead use some filter for CN, which is unique. should be only a couple of lines in the source, maybe it is already implemented (but I'm no expert here). of course there are more things that could be analyzed to verify this theory, but I doubt such data will create new insights. so I'm no expert on this topic, but I guess the code in opensc is good in general - while the improved version breaks your use case, it fixes other peoples use case. and while they had a real problem that was fixed, it looks to me like here you have a strange card and an application, and the issue is your card/application combo. so this is nothing opensc should fix per se. we could add ugly hacks to workaround that issue (e.g. a pkcs#11 module that lies and doesn't show all the certificates it has available), but I see little reason for that - it should be much, much, much easier to improve your application. Doing 'ipsec listcards' in strongswan gives me different results with working/nonworking opensc: working one shows my name in subject, nonworking one shows subject: 'C=DE, ND=1, CN=NKS 08 A 78205', both for id 46. only that one? or several? if only one is shown, that looks wrong, as the log files we have indicate that the not_ok version finds more than the ok version. so extra entries are fine. content replaced looks like a real bug - two certs are found, but the second is never looked at. (again, that would be an application bug I guess...) So any other ideas how pkcs11 could again perform with the old behaviour? you could write a filter module, that hides the unwanted certificates. but it would be much easier, if the applications looked for the right cert with a CN search, and not with an ID search. Thanks for the idea.. guess if noone else here has an idea i will approach strongswan list.. should be much easier than poking around opensc code, as in general opensc changes look fine to me, and seem to me other peoples real issues (where the problem doesn't seem to be a card/app combo). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc-pkcs11.so displaying certs differently?since opensc 0.11.10?
btw, can't you simply download your certificate as file, place it in /etc/ somewhere, and specify it in strongsswan.conf with leftcert= as filename (instead of %smartcard syntax)? that should work well. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] New OpenSC and OpenCT released
New versions of OpenSC and OpenCT are released today, with improvements for Rutoken S driver mostly. New in OpenCT 0.6.20; 2010-02-16; Andreas Jellinghaus * Modify Rutoken S binary interfaces by Aktiv Co. * Makefiles fixed in doc/ directory http://www.opensc-project.org/files/openct/openct-0.6.20.tar.gz New in OpenSC 0.11.13; 2010-02-16; Andreas Jellinghaus * Modify Rutoken S binary interfaces by Aktiv Co. * Muscle driver fixed (acl reading issue) * Many small fixes (e.g. mem leaks) * Compiling with openssl 1.0.0-beta fixed http://www.opensc-project.org/files/opensc/opensc-0.11.13.tar.gz Please note that OpenSC is currently under developing for a new 0.12.* release line. Thus only a few selected changes have been backported into the OpenSC 0.11.13 maintenance release. The majority of changes in the last few months is only available in the svn trunk development repository until a new 0.12.* release is available. Please give these new releases a try. If you encounter any problem with the new versions, please let us know. Thanks! Regards, Andreas ___ 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
[opensc-devel] Envoi d'un message : build-mi ngw32.patch
Hello Alon, Can you have a look on joined patch if it's ok for you. It's for building process for mingw32 using internal-winscard.h instead of Winscard.h (like we add cardmod.h I think we can add this minors modification). What do you think about? François. build-mingw32.patch Description: build-mingw32.patch ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Envoi d'un message : build-mingw32.patch
Looks nice. I think that something like: #include ../src/libopensc/internal-winscard.h Is simpler, no? 2010/2/16 François Leblanc francois.lebl...@cev-sa.com Hello Alon, Can you have a look on joined patch if it's ok for you. It's for building process for mingw32 using internal-winscard.h instead of Winscard.h (like we add cardmod.h I think we can add this minors modification). What do you think about? François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Envoi d'un message : build-ming w32.patch
you should never need this part:
--- trunk/build (révision 100)
+++ trunk/build (copie de travail)
@@ -239,7 +239,7 @@
echo Build opensc
cd ${BUILDROOT}/opensc* || die cd opensc
./configure ${CONFIGOPTS} ${EXTRA_OPENSC_CONFIG} \
- CFLAGS=${CFLAGS} --include=cardmod-mingw-compat.h -
I${SCRIPTROOT}/include \
+ CFLAGS=${CFLAGS} --include=cardmod-mingw-compat.h -
I${SCRIPTROOT}/include -I./src/libopensc \
--enable-openssl --enable-zlib ${extra_opensc} --enable-doc \
|| die Configure opensc
${MAKE} ${MAKEOPTS} ${MAKE_AUTOCONF_INSTALL_TARGET}
DESTDIR=${OPENSC_ROOT} || die make opensc
if some file inside opensc source is not found, then it is propably
an issue with some Makefile (e.g. FOO_CFLAGS += -I${srcdir} needed).
can you give details why/when this is needed, so we can find out
what is wrong?
and the internal file is better referenced with filename.h I think.
Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Envoi d'un message : build-min gw32.patch
if some file inside opensc source is not found, then it is propably
an issue with some Makefile (e.g. FOO_CFLAGS += -I${srcdir} needed).
can you give details why/when this is needed, so we can find out
what is wrong?
This is needed to cross build opensc with cardmod support with mingw32
since winscard.h not present in this case. So to configure --enable-carmod
witch detect cardmod.h header and in this header we need winscard.h or
internal-winscard.h
Under mingw64 winscard.h is present under mingw32 we can use
internal-winscard.h
But for now configure detect cardmod.h and can't include internal-winscard.h
(not
Found in config.log so build process fail with cardmod.h not usuable)
and the internal file is better referenced with filename.h I think.
I will try Alon suggest:
http://www.opensc-project.org/pipermail/opensc-devel/2010-February/013447.html
Regards, Andreas
Thank you,
François.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Envoi d'un message : build-ming w32.patch
Am Dienstag 16 Februar 2010 13:57:07 schrieb François Leblanc: This is needed to cross build opensc with cardmod support with mingw32 since winscard.h not present in this case. So to configure --enable-carmod witch detect cardmod.h header and in this header we need winscard.h or internal-winscard.h we ask people to download microsoft CNG SDK for cardmod.h, they could do the same to download winscard.h. or we could put the adapted winscard.h file we have as internal-winscard.h (used only for mingw32 builds, right?) on the webserver in contrib, in the build project, or into win32 or mingw or contrib directories inside opensc. so the configure would be simple and clean -- an enable option for users to show they want to build with that, and a with option to point to the directory with these files. the include would be a simple #include winscard.h or #include cardmod.h and we can give detailed instructions where people can get those files (pcsclite-dev on linux/unix and plattform SDK on windows), or what alternatives they have (the file from contrib/build project/whatever). what do you think? would this work? or did I miss something - how exactly is winscard.h used? I find it strange that we need to fix a mingw32 bug with strange code in opensc, and would prefer a cleaner solution, or at least find out the details and document them somewhere. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] remove cardmod pcsc driver from internal.
Hello, In file src/libopensc/ctx.c: since 'cardmod' driver is a subset of pcsc drivers it should not be use with pcsc driver, if we use the internal keyword (by default) cardmod is loaded too and may conflict with pcsc reader. So I propose to change this with joined patch if someone get better idea I can have a look. Thank you, François. cardmod-ctx.patch Description: cardmod-ctx.patch ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
