Hello Stef, I think that each project is targeting a different set of problems.
I am fully opened for discussion, but this is how I see things: pkcs11-helper targets developers who like to introduce PKCS#11 into their application, especially for smartcard. It allows to minimize the user interaction and maximize the object reuse. While using the minimum set of the specification in order to allow application compatibility with most implementation. p11-kit designed to solve incompatibilities of modules and inappropriate implementation of application that use PKCS#11 by providing a baseline of the PKCS#11 spec module implementation that may proxy on or more providers. BTW: we should also outline the difference between p11-kit and NSS. Let's take your example and see where these fit: > * Coordinating initialization and finalizing. You referencing a bad implemented application that is use PKCS#11 in two independent places. A practical solution is to fix the library implementation (such as GnuTLS) to provide some state information. However, a proxy baseline provider with reference count and such may indeed solve this issue. > * A standard place to put configuration of which modules to load > and how to load them. A PKCS#11 aware application should be expose to this information and not let some library to hide these. I also don't like libraries like NSS that have dependencies out side of the runtime environment the application is creating for them. > * Allowing pkcs11-helper to load modules from a standard > location. Does pkcs11-helper have a concept of a module > registry? If not, this could be a nice addition provided > by p11-kit. Same as above. I don't like these registries within a library (API). A proxy module may have its own configuration which is fine. > * Initializing modules via p11-kit so that refcounting, and > pInitArgs stuff works if more than one app/library in the > same process uses a PKCS#11 module. I written above, a different (applicative) solution should be applied. > * Safe forking (pkcs11-helper already does this, but p11-kit > forking stuff integrates with the initialization refcounting). Yes, much of the work in pkcs11-helper was safe forking, in order to abstract the [complex] process from the developers. What do you think? Alon. On Mon, Aug 1, 2011 at 8:11 AM, Stef Walter <st...@collabora.co.uk> wrote: > > Hi Alon, > > Thanks for all the PKCS#11 integration work you've spearheaded across > the community. > > You may have heard of p11-kit before. It tries to solve several problems > with using PKCS#11 modules across the Desktop. In particular when > multiple applications or libraries want to use the same PKCS#11 modules. > Most importantly: > > * Coordinating initialization and finalizing. > * A standard place to put configuration of which modules to load > and how to load them. > > More documentation here: http://p11-glue.freedesktop.org/p11-kit.html > > p11-kit can be used as a PKCS#11 module, and as such will integrate out > of the box into anything that supports PKCS#11. So pkcs11-helper can > already use p11-kit. > > I'm interested in integrating p11-kit more closely into pkcs11-helper. > But I figured I'd talk with you before hacking. Some areas where > integration could take place: > > * Allowing pkcs11-helper to load modules from a standard > location. Does pkcs11-helper have a concept of a module > registry? If not, this could be a nice addition provided > by p11-kit. > > * Initializing modules via p11-kit so that refcounting, and > pInitArgs stuff works if more than one app/library in the > same process uses a PKCS#11 module. > > * Safe forking (pkcs11-helper already does this, but p11-kit > forking stuff integrates with the initialization refcounting). > > Perhaps more? How do this sound? > > Cheers, > > Stef _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
