Re: [opensc-devel] build fatal
François Leblanc wrote: Hello I can’t build anymore opensc, get failure : Cannot export sc_der_clear: symbol not defined Should I remove « sc_der_clear » from libopensc.exports list ? Any objections ? Yes, it was not used. François. Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] serial number of USB smart card adapters
On Feb 9, 2010, at 12:56 , Andreas Jellinghaus wrote: usualy a smart card or usb crypto token has certificates on it, and they can be read without any user verification. so monitoring is always possible in such setups. That's one way of approaching it, and things like public eID cards (where information is visually available from the card anyway) follow the logical path of not hiding that public information. Firefox/NSS for example assumes by default the opposite - that nothing is available from the card unless you first authenticate to it (the friendly certs feature, discussed several times before). Taking into account the specific usage scenario of the CryptoStick (tool for privacy-aware people) it is justified, just as well is the PIN before anything justified for scenarios where access to data in the card would compromise confidentiality. btw, does anyone know a native card OS that supports duress passwords? (entering a specific password would erase key material in the card) -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] new ubuntu packages
Thanks to Stephan Hermann new openct and opensc packages for ubuntu are available: https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu2 https://launchpad.net/ubuntu/+source/opensc/0.11.12-1ubuntu1 To my knowledge they contain all the changes and fixes we wanted for packaging, so Ubuntu 10.04 lucid will have working smart card packages. If you can help with testing, that would be very welcome. The lucid packages can't be installed on ubuntu karmic, as karmic libopenssl and libltdl7 are too old for that. But ubuntu has daily cd images here: http://cdimage.ubuntu.com/daily-live/current/ And the next milestones are: 2010-02-25 Alpha 3 2010-03-20 Beta 1 As an alternative I backported the packages to karmic (and fixed minor issues in openct - shouldn't matter to users) and placed them here: http://www.opensc-project.org/ubuntu/ So I hope we can test everything to make sure this time everything works well. Help would be very welcome! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new ubuntu packages
Hello, Andreas Jellinghaus wrote: Thanks to Stephan Hermann new openct and opensc packages for ubuntu are available: https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu2 https://launchpad.net/ubuntu/+source/opensc/0.11.12-1ubuntu1 To my knowledge they contain all the changes and fixes we wanted for packaging, so Ubuntu 10.04 lucid will have working smart card packages. If you can help with testing, that would be very welcome. OpenCT-0.6.19 was released after changeset 1174 in OpenCT [1] and changeset 3865 in OpenSC [2], but OpenSC was not released. OpenCT-0.6.19 + OpenSC-0.11.12 don't work with Rutoken S. [1] http://www.opensc-project.org/openct/changeset/1174 [2] http://www.opensc-project.org/opensc/changeset/3865 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new ubuntu packages
hmm. for openct we can create a new release. are there any other pending changes, that should go into an openct release? for opensc a 0.12 release from trunks is several weeks away, as we are still doing many cleanups and changes. we could release another 0.11.* with a backport of some changes. what patches would be candidates for that? your rutoken improvements? what else? for ubuntu we are too late anyway, as today is the deadline for new debian syncs / new versions. only bug fixes from this point on, so getting a new version of some package into ubuntu is unlikely. but does anyone know when the debian freeze is? IIRC they plan some major new version too, so we should try to get working packages in debian too. for all other distributions I have little clue about their release schedule and what the status of opensc and friends in those is etc. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new ubuntu packages
Andreas Jellinghaus wrote: for all other distributions I have little clue about their release schedule Gentoo is easy - submit new ebuilds to bugzilla and if they're clean they will end up in the public portage tree. If a Gentoo developer gives it priority in their workqueue it happens in a few hours. what the status of opensc and friends in those is etc. openct-0.6.19 07 Jan 2010 (marked unstable, meaning not well tested) opensc-0.11.12 19 Dec 2009 (marked stable 03 Feb 2010) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new ubuntu packages
Am Donnerstag 11 Februar 2010 13:27:08 schrieb Ludovic Rousseau: So no idea when the Debian freeze will happen. ok. but that still indicates we should get working packages into debian soon, as one a freeze is announced, only bugfixes are allowed, but no new versions of something IIRC. Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Regression test in src/tests/regression
Hello Jean-Michel, Jean-Michel Pouré wrote: Dear friends, Would it be possible to discuss about regression tests. I would like to review these tests to certify a number of cards. On my system, regression test fail during erase because pkcs15-init -E may return messages and fail. In particular, running pkcs15-init twice fails: http://www.opensc-project.org/opensc/ticket/195 Regression test make heavy use of blanking cards. I see a lot of changes in SVN these last days. Would it be possible for you to change/fix regression test and/or make initialization work. If this is not possible, feel free to explain why and how we could modify regression tests. Actual pkcs15init support for card 'feitian' works only with 'onepin' profile. Afais, only two tests 'erase', and 'init0012' concerns this configuration. The both are OK in OpenSC rev.4014 . Pkcs15init support of 'feitian' is not comlete: - in profile there are four pins defined, but all have the same reference and flags (just copypast); - ACLs defined by profile are ignored and fixed inside the card specific code (all ACLs not 'NEVER' are 'ALWAYS'); - according to profile the PIN are globals, but in fact they are created as locals; - only one PIN is allowed (it seems that card itself allows more). Thanks in advance, Jean-Michel Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new ubuntu packages
It would be nice if you could add to opensc 0.11.11 Alexey's Samsonov patches for Rutoken S. They tested by me. In this case Rutoken S would work in Ubuntu and there would be no problems with the inclusion of unstable version 0.12 Regards, Cyril ___ 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 openct changed[1181] For packaged tar. gz files with builds inside the source,
Am Donnerstag 11 Februar 2010 13:49:05 schrieb Alon Bar-Lev: No it isn't... The generated files should not be cleaned if .tar.gz is used, only if this is svn checkout, as we assume that we can make dist offline. hu? sorry, I don't understand what your point is. my preference is this: * people should be able to build svn without docs (well, pretty low priority these days, as all distributions have everything needed packaged already) * if documentation is generate during build, it should be gone after make maintainer-clean so I get a proper diff between my changed checkout and my unchanged checkout. * if documentation is generated and I run make dist, it should end up in the tar.gz file, so I can ship the file with pre-generated documentation (similar to autoconf/make/.. files, they are included too). * if people use a tar.gz and run make clean or make distclean the documentation should not be removed - we didn't change it, we didn't create it, so we shouldn't remove it either. and that last point is the issue: debian build scripts run make dist-clean before they generate diffs. with the old Makefile.am/in the pre-generated api.out would be gone. even worse: replaced by a symlink loop, and thus cause a build error, if someone tries to build from the same folder once more. so how do we fix this? if api.out is created by makefile, then it should be removed by the makefile. if not, it shouldn't be touched. one - not very nice - way would be to generate documentation from bootstrap script. yes, that looks wrong, but it would put the documentation on the same level as Makefile.in and configure script - all the files we pre-build so they can be included in tar.gz files and are maintainer status (i.e. only change if --enable-maintainer and are only deleted with make maintainer- clean) would be done by the same process. or maybe automake has a mechanism we can hook into? I'm not sure if my fix is right or wrong - so I'm asking. but I'm sure we have a problem. for the distribution I send them a quick fix: -rm -fr api.out is replaced by -rm -f api.out, so it is will delete the api.out symlink, but not the api.out directory. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] new 0.11.13 branch for 0.11.* updates
Hi, I create an 0.11.13 release branch for changes we want to see in the next 0.11.* release. please: only small, well tested changes. make sure it compiles and works well with the 0.11.* code (which is now quite different from current trunk). svn co https://www.opensc-project.org/svn/opensc/releases/opensc-0.11.13 will give you a checkout of that branch. I'm offline over the weekend, so I can't create a new release before next week. if anyone else wants to fill in, feel free to do so (but coordinate here with everyone 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-commits] svn opensc changed[4019] libopensc: in
Am Donnerstag 11 Februar 2010 15:18:30 schrieb Viktor TARASOV: webmas...@opensc-project.org wrote: Revision: 4019 Author: viktor.tarasov Date: 2010-02-11 14:15:13 + (Thu, 11 Feb 2010) Log Message: --- libopensc: in Sorry, its gone without complete comments. Correct one is: libopensc: when connecting card, try at the end the drivers that need some APDU transactions to recognize its cards. I'm no expert, but the javacard driver should be _after_ muscle I think, as it is the fallback, if no matching applet is found on the card. I fear you will break muscle with that change. you can test yourself, one of the two cyberflex tokens on route to you has a musclecard applet on it, as far as I remember. 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-commits] svn opensc changed[4019] libopensc: in
On Feb 11, 2010, at 16:23 , Andreas Jellinghaus wrote: Am Donnerstag 11 Februar 2010 15:18:30 schrieb Viktor TARASOV: webmas...@opensc-project.org wrote: Revision: 4019 Author: viktor.tarasov Date: 2010-02-11 14:15:13 + (Thu, 11 Feb 2010) Log Message: --- libopensc: in Sorry, its gone without complete comments. Correct one is: libopensc: when connecting card, try at the end the drivers that need some APDU transactions to recognize its cards. I'm no expert, but the javacard driver should be _after_ muscle I think, as it is the fallback, if no matching applet is found on the card. I fear you will break muscle with that change. It has to be after applet cards indeed. What about EMV - we don't support EMV cards in any way and probably never will in near future, do the EMV card, but can't do anything with it information seems useful or not? I would suggest to remove the emv driver and leave such tasks to pcsc_scan instead (unlike JavaCards where we should get a tutorial on how to load and personalize an applet to use with OpenSC). -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new 0.11.13 branch for 0.11.* updates
On Feb 11, 2010, at 16:13 , Andreas Jellinghaus wrote: Hi, I create an 0.11.13 release branch for changes we want to see in the next 0.11.* release. Are there any *critical* issues that need to be fixed at all? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ 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[4019] libopensc: in
Am Donnerstag 11 Februar 2010 15:27:56 schrieb Martin Paljak: What about EMV - we don't support EMV cards in any way and probably never will in near future, do the EMV card, but can't do anything with it information seems useful or not? I all for it. in fact unusable driver seem to confuse users, we had a number of mails asking for help, when there was no complete driver. so maybe it is best to disable all drivers that are only stubs. that would include acos5 too, for example. I would suggest to remove the emv driver and leave such tasks to pcsc_scan instead (unlike JavaCards where we should get a tutorial on how to load and personalize an applet to use with OpenSC). btw: any idea how difficult it is to load a java applet on a javacard? I know gpshell and other projects can do that. if it is complex, we should point people there, but if it is easy, as sending a few APDUs with the code as payload, then we could write a small tool for that, so people had one less tool/dependency to worry about. not sure what is best here. 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-commits] svn opensc changed[4019] libopensc: in
On Feb 11, 2010, at 16:34 , Andreas Jellinghaus wrote: Am Donnerstag 11 Februar 2010 15:27:56 schrieb Martin Paljak: What about EMV - we don't support EMV cards in any way and probably never will in near future, do the EMV card, but can't do anything with it information seems useful or not? I all for it. in fact unusable driver seem to confuse users, we had a number of mails asking for help, when there was no complete driver. so maybe it is best to disable all drivers that are only stubs. that would include acos5 too, for example. Agreed. ACOS5 is easy to get, they have a public doc and and they are quite cheap. Hopefully somebody steps up when there is time to write a crypto-aware driver for it. I'll remove the emv when moving the Javacard piece as well. I would suggest to remove the emv driver and leave such tasks to pcsc_scan instead (unlike JavaCards where we should get a tutorial on how to load and personalize an applet to use with OpenSC). btw: any idea how difficult it is to load a java applet on a javacard? ./gpj.sh -load applet.cap -install -list I know gpshell and other projects can do that. if it is complex, we should point people there, but if it is easy, as sending a few APDUs with the code as payload, then we could write a small tool for that, so people had one less tool/dependency to worry about. not sure what is best here. I think that it is easier to re-use others code for the task of loading the applet. There are various applets and various preferences, so maybe just focus on a few ones and document the process. Unfortunately, different javacards behave differently and there's no universal loading procedure. I personally use gpj from sf.net, it provides a simpler interface than gpshell for me. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ 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 openct changed[1181] For packaged tar. gz files with builds inside the source,
If you offline and do make distclean and you remove the generated files then if you try to make dist you: 1. Must be online while compiling. 2. Must use more tools which autoconf will not configure: XSLTPROC, SVN, TR, WGET Compiling from svn does not require you to have dependency if you don't have --enable-doc but you must have these dependencies in order to make dist. As we discussed in the past, a proper solution to the problem is not to fetch changelog or documentation from external resources in opensc package, while producing opensc-doc package that does this and can be installed separately. Alon. On Thu, Feb 11, 2010 at 4:00 PM, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Donnerstag 11 Februar 2010 13:49:05 schrieb Alon Bar-Lev: No it isn't... The generated files should not be cleaned if .tar.gz is used, only if this is svn checkout, as we assume that we can make dist offline. hu? sorry, I don't understand what your point is. my preference is this: * people should be able to build svn without docs (well, pretty low priority these days, as all distributions have everything needed packaged already) * if documentation is generate during build, it should be gone after make maintainer-clean so I get a proper diff between my changed checkout and my unchanged checkout. * if documentation is generated and I run make dist, it should end up in the tar.gz file, so I can ship the file with pre-generated documentation (similar to autoconf/make/.. files, they are included too). * if people use a tar.gz and run make clean or make distclean the documentation should not be removed - we didn't change it, we didn't create it, so we shouldn't remove it either. and that last point is the issue: debian build scripts run make dist-clean before they generate diffs. with the old Makefile.am/in the pre-generated api.out would be gone. even worse: replaced by a symlink loop, and thus cause a build error, if someone tries to build from the same folder once more. so how do we fix this? if api.out is created by makefile, then it should be removed by the makefile. if not, it shouldn't be touched. one - not very nice - way would be to generate documentation from bootstrap script. yes, that looks wrong, but it would put the documentation on the same level as Makefile.in and configure script - all the files we pre-build so they can be included in tar.gz files and are maintainer status (i.e. only change if --enable-maintainer and are only deleted with make maintainer- clean) would be done by the same process. or maybe automake has a mechanism we can hook into? I'm not sure if my fix is right or wrong - so I'm asking. but I'm sure we have a problem. for the distribution I send them a quick fix: -rm -fr api.out is replaced by -rm -f api.out, so it is will delete the api.out symlink, but not the api.out directory. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problems developing with Starcos 2.3
Fernando Sanchez Chaparro wrote: Hi Andreas, Thank you very much for your answer. 2010/2/4 Andreas Jellinghaus a...@dungeon.inka.de mailto:a...@dungeon.inka.de Hi Fernando, your problem is this: starcos_ops.delete_file = NULL; the starcos driver does not implement delete file. I'm not sure of the details, maybe it is a limitation of the card (i.e. starcos does not offer any way to delete files). not 100% sure. it could also be that the driver author didn't implement it for some reason. but I guess it is rather a card limitation. check the starcos manual for details (available by mail from gd, simply ask them for a copy). if there is a way to delete objects, patches to implement that are welcome. Good! I'll look into this question checking the Starcos manual in order to find out what possibilities we have with this kind of card, and I'll keep you posted. I've got specifications of the StarCOS cards. STARCOS-2.1 and -2.3 have no possibility to delete EF or DF. In test cards there is special command to delete MF. For STARCOS-3.0 DF and EF can be deleted and self-deleted. Regards, Andreas Regards. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new 0.11.13 branch for 0.11.* updates
Am Donnerstag 11 Februar 2010 15:32:15 schrieb Martin Paljak: On Feb 11, 2010, at 16:13 , Andreas Jellinghaus wrote: Hi, I create an 0.11.13 release branch for changes we want to see in the next 0.11.* release. Are there any *critical* issues that need to be fixed at all? no. but I'm happy to create new 0.11.* releases that fix small issues. developing a new major version doesn't rule out fixing bugs / problems in the last major line. to the contrary, if enough manpower is available, I think it is best practise to do so. and since driver changes are small and isolated, and aleksey is very active as developer and with testing, I see no reason not to do a new release for those changes. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
