Am Montag 21 September 2009 08:43:16 schrieb Alon Bar-Lev: > On Sun, Sep 20, 2009 at 6:25 PM, Martin Paljak <mar...@paljak.pri.ee> wrote: > > > 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? > > First, I like the modulation. It is much simpler to maintain modulated > piece of software.
well, good maintenance should include clean interfaces between the modules and documenting the interfaces. we completely failed here, we have many symbold exported, but sometimes not enough, and we have no good api documentation, and in many parts the decission where something was implemented is not a good design, but simply historic development. also some designs are no longer important: for example I haven't heard of anyone trying to build opensc-pkcs11.so without support for pkcs15init, which was one reason to keep that code modular. also while it is possible in opens to have frameworks other than pkcs15, noone implemented one, and it is unlikely anyone ever will. > Second, it is a very bad idea to provide a PKCS#11 library with none > PKCS#11 exports. true. but the question is rather: keep some hack so openssh can be used with opensc, or remove everything except pkcs#11 symbols? I wouldn't like to kill opensc support in openssh, unless we have a lightwight patch to enable it with pkcs#11. (i.e. not a patch that adds full x.509 stuff. I know you have one that does this, but for me it's not simple enough, so I prefer a much easier system with openssh). ah, one more issue: what about our internal tools? opensc-tool, opensc-explorer, pkcs15-init, etc.? they need to be able to use the internal api, and I doubt we can rewrite them to use pkcs11 only. (in fact we don't need to, pkcs11-tool should be able to do everything pkcs#11 has to offer). so I think we are back to two binaries - libopensc.so and opensc-pkcs11.so - or more (keep scconf as standalone lib? keep pkcs15init as standalone lib?). > Merging between libopensc and libpkcs15init is making sense, but what > the benefit will be? > Anyway two options: > 1. Make the libpkcs15init internal library (.a) it will not be > distributed, but linked against executables. > 2. Merge libopensc and libpkcs15init into a single library. I favor 2. but without moving all code around, unless that really helps. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
