On 18.09.2009, at 12:02, Andreas Jellinghaus wrote: > Am Donnerstag 17 September 2009 10:41:56 schrieb Martin Paljak: >> I'm not an expert on pkcs15init nor know the historical and >> philosophical reasons for the separation between libopensc and >> pkcs15init. > I guess noone is. lets considere it historic development.
I thought the same. >> I'll push the change to my 0.12 branch for review, but I have a few >> questions that can be answered without the patch: >> - Why a separate pkcs15init library? Are there any real life users >> of the separate library? What are the reasons? Do we need it? Why not >> a single libopensc.so? > > not sure if the changes we have so far break ABI. but if we break ABI, > then I favor to merge libopensc, libpkcs15init and opensc-pcks11.so > into one library / shared object. Hmm, that is an interesting idea. It would also have to include scconf which currently is distributed separately, but then again is also used by other software like pam_pkcs11 for example. Alon, what do you think of it (from the build system POV) and do you think you have the interest and time to work on it? >> - Do we really need 3 implementations for PIN caching? > I don't see why, but I'm no expert either. There's an undocumented option to pkcs15-init, --secret, that is used by the regression tests and make use of sc_keycache things by feeding CHV/PIN codes to the pkcs15init system. Why a secret option? Why --pin and --so-pin can not be used? I only have muscle/oberthur/cryptoflex/ epass3000 to test with when I remove it. I hope it is enough. > I would love if opensc could simply stay verified, i.e. read public > objects from the card once and answer them from memory, AFAIK it also does, during the lifetime of a PKCS#11 application at least. File caching should help as well, but it needs more work to be useful. But after all, the card is the place that has the ultimate knowledge about the state of keys and PIN-s... > and if it > gets a pin then verify once. and if the card allows several operations > (e.g. rsa signing etc.) without re-entering the pin, it shoud do that. For example Estonian eID works this way, with OpenSC. >> My suggestion would be to remove pkcs15init as a separate library and >> have a single libopensc.so > > why keep the internal API? only openssh uses them. we could merge > opensc-pkcs11.so as well into libopensc so people can use > a) libopensc with many functions available > b) if they onlye use PKCS#11 they can access the symlink opensc- > pkcs11.so > > but only have one binary left. As I said, that's a funky idea. Unfortunately for some time (until it gets fixed in Firefox) there must be hacks like onepin-opensc- pkcs11.so which does not support the single binary idea... > if we break abi, we should create an export file so we clearly define > which functions we want to export, and which not, and also cleanup > the header files to reflect that. It can be a step-by-step move. We declare PKCS#11 as THE interface, combine *.export files for compatibility, then gradually refine the API and headers (which should then only be used by OpenSC tools) >> Answers to questions and thoughts on this subject are most welcome. > > about those details: you know them much better than I do, so I can't > comment on that. > > other things we could clean up: > * keep or remove the code to load drivers as plugins? Last time Nils said he knows at least two such drivers. > * keep license LGPL 2.1+ or change to LGPL 3.0+? What are the differences and why? > * keep allowing drivers with no source or mandate changes > to libopensc be LGPL'ed (or compatible)? I'm not an expert but to my understanding all libopensc modifications that get distributed must come with source? > * remove the UI code? Yes. > * remove the nsplugin code? Yes. -- 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
