[xmlsec] loading crypto engines as plugins

[John Belmonte]

Aleksey wrote:
> 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.

Regards,
-John



-- 
http:// if   le.o  /