[opensc-devel] debian package description
I filled a bug concerning it, so I hope Eric (the debian maintainer) can change it, when creating the next package. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552516 Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC 0.11.11 released today
OpenSC 0.11.11 released today updated the "myeid" driver and fixes compiling issues with OpenSSL 0.9.7 and 1.0.0. http://www.opensc-project.org/files/opensc/opensc-0.11.11.tar.gz Development is now focused on a new 0.12.* branch of OpenSC. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] opensc: simplify nsplugin build
On 26.10.2009, at 12:35, Diego Elio “Flameeyes” Pettenò wrote: > Il giorno Mon, 26/10/2009 alle 12.22 +0200, Martin Paljak ha scritto: >> >> So it seems we have a nsplugin user and new developer? >> Do you use it? Would you be willing to maintain/develop it? > > Actually, no to all counts. > > I just stumbled across this after last opensc update in Gentoo; I'm > doing QA work in Gentoo and one of the things I take care of usually > is > ensuring that plugins don't get static archives and .la files built > and > installed, so I checked the buildsystem and patched it up (as well as > fixing installation path in Gentoo). > > Sorry for giving hope about that. No worries, this is still a sign that the only effort that has gone into signer during past 8 years have been "update to fix compilation issues" type of stuff. I still suggest to reap it out and re-package as a separate entity only after somebody discovers that it is used. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] opensc: simplify nsplugin build
On 26.10.2009, at 12:22, Martin Paljak wrote: > As I've also written a web signing plugin for Firefox/Opera/Safari I > can say it has changed from "Netscape plugins" to a more useful, > cross-browser API. I don't know if the current signer can do it. But > it's not trivial, for example on OS X plugins can have 3 or four > different entry ways into the plugin, depending on CPU architecture > and browser - different browsers (Namely Opera) do it a bit > differently, at least they used to 1.5 years ago. For more info: http://en.wikipedia.org/wiki/NPAPI#Scripting_support signer code is 8 years old ~2001. A modern plugin would expose a scriptable object, use the browser/modal windows for user interaction etc. > > On 24.10.2009, at 16:34, Diego Elio “Flameeyes” Pettenò wrote: > >> The attached patch simplifies the Makefile.am support for building >> the >> nsplugin. Beside removing the recursion inside npincludes (unneeded), >> and avoiding entering the directory entirely when nsplugin is >> disabled, >> it also avoids building the static copy of the plugin itself (see >> [1]) >> and at the same time installs it directly inside the nsplugin >> directory, >> rather than sing a symlink (and “polluting” the main library >> path). >> >> HTH, >> >> [1] >> http://www.flameeyes.eu/autotools-mythbuster/libtool/index.html#libtool.plugins.dlopen >> >> -- >> Diego Elio Pettenò — “Flameeyes” >> http://blog.flameeyes.eu/ >> >> If you found a .asc file in this mail and know not what it is, >> it's a GnuPG digital signature: http://www.gnupg.org/ >> >> > simplify.patch>___ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- > Martin Paljak > http://martin.paljak.pri.ee > +372.515.6495 > > > > -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] opensc: simplify nsplugin build
Il giorno Mon, 26/10/2009 alle 12.22 +0200, Martin Paljak ha scritto: > > So it seems we have a nsplugin user and new developer? > Do you use it? Would you be willing to maintain/develop it? Actually, no to all counts. I just stumbled across this after last opensc update in Gentoo; I'm doing QA work in Gentoo and one of the things I take care of usually is ensuring that plugins don't get static archives and .la files built and installed, so I checked the buildsystem and patched it up (as well as fixing installation path in Gentoo). Sorry for giving hope about that. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] opensc: simplify nsplugin build
Hi, So it seems we have a nsplugin user and new developer? Do you use it? Would you be willing to maintain/develop it? nsplugin has not seen any real *development* for 8 years : http://www.opensc-project.org/opensc/log/trunk/src/signer As I've also written a web signing plugin for Firefox/Opera/Safari I can say it has changed from "Netscape plugins" to a more useful, cross- browser API. I don't know if the current signer can do it. But it's not trivial, for example on OS X plugins can have 3 or four different entry ways into the plugin, depending on CPU architecture and browser - different browsers (Namely Opera) do it a bit differently, at least they used to 1.5 years ago. If there are users who use the otherwise almost dead code, we can extract it and leave it for those who want it, the way it currently is. It would use a deprecated API (directly libopensc), compete with pkcs11.sign() method of Firefox, would not work on other browsers and would not have any real documentation or designed features. On 24.10.2009, at 16:34, Diego Elio “Flameeyes” Pettenò wrote: > The attached patch simplifies the Makefile.am support for building the > nsplugin. Beside removing the recursion inside npincludes (unneeded), > and avoiding entering the directory entirely when nsplugin is > disabled, > it also avoids building the static copy of the plugin itself (see [1]) > and at the same time installs it directly inside the nsplugin > directory, > rather than sing a symlink (and “polluting” the main library > path). > > HTH, > > [1] > http://www.flameeyes.eu/autotools-mythbuster/libtool/index.html#libtool.plugins.dlopen > > -- > Diego Elio Pettenò — “Flameeyes” > http://blog.flameeyes.eu/ > > If you found a .asc file in this mail and know not what it is, > it's a GnuPG digital signature: http://www.gnupg.org/ > > simplify.patch>___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Release 0.12
Hi, >> 2. p15emu-westcos.c. Problem: consistent naming. Rest of the emulation >> drivers use pkcs15-.c As there are pkcs15-foo.c files in src/ >> libopensc that deal with other tasks than emulation, maybe push the >> emulation drivers into a subdirectory for clarity? > >I'm fine with renames. a subdirectory below src/ ? >(i.e. not src/libopensc/pkcs15emu). > >also I would be fine with merging directories, or other bigger strutural >changes. now is a good time to discuss what changes we can do and if >those will help us to structure the code better, make it easier to >understand >and maintainer it easier. Warning, there are pkcs15-westcos.c in pkcs15init dir so if you change the name you will have a problem merging pkcs15init into libopensc (is the reason why I've kept p15emu-westcos instead of pkcs15-westcos). More other pkcs15- in libopensc concern emulated cards, so I suggest to rename all pkcs15-.c in libopensc by p15emu-.c and change pkcs15-foo.c name (if it deal other than emulation). (I use both since I have small westcos 2ko without pkcs15 structure inside and bigger one where I can put pkcs15 structure... Perhaps other cards can have the same so it will be great to keep it possible and have a convention naming that let us do it...) Regards, François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Online ATR parsing
2009/10/25 Martin Paljak : > > On 04.10.2009, at 17:51, Ludovic Rousseau wrote: > >> 2009/10/4 Martin Paljak : >>> >>> On 04.10.2009, at 16:30, Ludovic Rousseau wrote: > > - it could also use smartcard_list.txt to display more info about the > ATR/card. Done (without regular expression for now). >>> >>> Don't know if it requires regexps or not but Estonian eID ATR >>> 3b:5e:11:ff:45:73:74:45:49:44:20:76:65:72:20:31:2e:30 is not identified. >> >> This card was not in my list. Corrected. > > Strange, I thought I have sent all ATR-s used by EstEID, but apparently I > was wrong :) Probably because of cold/warm ATR difference... The complete list is available at http://ludovic.rousseau.free.fr/softwares/pcsc-tools/smartcard_list.txt >>> Maybe keep the input bar on the parse page as well, so that a new ATR >>> could >>> be entered at once. Also, it would be better if the input field was just >>> a >>> looong single line, from left side to right side of the browser window. >> >> I am now using: >> >> > cols="100"> >> >> >> >> Patches welcome :-) > > > > > > > This way pressing return in the ATR field submits the ATR instead of > generating a newline inside the textarea. Thanks. I will try that. > It would be useful to also list all cards in smartcard_list.txt and maybe > even be able to browse them by some characteristics, like > http://pcsclite.alioth.debian.org/section.html. At least a listing of all > ATR-s with a link to parse page would be useful. The complete list is available online. It would be nice to submit an ATR parse with only one URL (by putting the ATR in the URL for example). So creating a web page with all the ATRs and links to the parsed version would be easy. But you could not easily "grep" the parsed ATRs in this case. I already have more than 800 ATRs in the list. What characteristics do you think would be interesting? - T=0, T=1, both support - speed (TA1) Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
