[xmlsec] loading crypto engines as plugins
jvb at prairienet.org
Fri Sep 5 12:59:54 PDT 2003
> I can do it in a couple days but first I would like to ask a question:
> does anyone have a need in such an improvement? Any use cases for it?
One case is the xmlsec tool. Instead of having xmlsec1-nss, etc., have
only xmlsec1 and select the engine at the command line. The xmlsec tool
is a model application for the xmlsec library-- things we can surmise
from this tool likely apply to any binary application using the library.
Another case is any new library that will depend on libxmlsec.
Currently, the author of such software might be tempted to propagate the
compile-time xmlsec option and make libfoo-openssl, libfoo-nss, etc.,
versions of his library. (Now if his library had it's own compile time
options, then you can see how things get ugly. We get libfoo-a-openssl,
libfoo-b-nss, etc. An then another new library depends on libfoo... and
so on.) It would be better if he could just distribute one version of
his library and let the xmlsec crypto enigne be selected by the user of
the library or on-site.
I don't know anything about the complexity of dlopen or security issues
of using plugins. I'm only commenting on the benefits of deferring
crypto engine selection.
http:// if le.o /
More information about the xmlsec