GNOME Bugzilla – Bug 121579
RFE: implement loading crypto engine as plugins
Last modified: 2004-12-22 21:47:04 UTC
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
I hope that libltdl from libtool can hide "complexity of dlopen". I think when we use lt_dlopen("/usr/libexec/xmlsec-nss.so") we shouldn't care about security. My /usr/libexec is full with apache modules ;-). We can have security problems with shared libs without dlopen. As example see for AIX and gcc "Portable OpenSSH: Dangerous AIX linker behavior (aixgcc.adv)" at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=105167884027821 For ms-windows os-es I think that we might have security problem what cannot be fixed - I't not recommended to use fixed paths to load dlls and might cannot fix dll search path.
Created attachment 19829 [details] [review] the first patch for MSCRYPTO branch: plugins are implemented with ltdl library, no windows code yet
Created attachment 19830 [details] [review] the first patch for CVS trunk: no windows support again
Created attachment 19834 [details] [review] cleanup in Windows makefile (mscrypto branch)
Created attachment 19836 [details] [review] cleanup in Windows makefile (trunk)
about attachment with id 19830 1.) === Patch contain (on one line !) #if !defined(XMLSEC_NO_CRYPTO_DYNAMIC_LOADING) && defined(XMLSEC_CRYPTO_DYNAMIC_LOADING) Why ? Both definition are mutually exclusive. What about config.h.in to contain: #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING # ifdef XMLSEC_NO_CRYPTO_DYNAMIC_LOADING # undef XMLSEC_NO_CRYPTO_DYNAMIC_LOADING # endif #endif 2.) === Now I see one problem. One crypto can have aes/des/etc. support, other without aes/des/etc. . Might we should have configure.ac for every crypto engine and in main configure.in to put macro AC_CONFIG_SUBDIRS() for allowed crypto engines. 3.) === I think that every crypto should init own struct xmlSecCryptoDLFunctions as usualy in C, i.e. static xmlSecCryptoDLFunctions functions = { ... xmlSecXXXInit, xmlSecXXXShutdown, xmlSecXXXKeysMngrInit, ... }; When definition of structure xmlSecCryptoDLFunctions is changed, on compile time we can detect this. On run time as in proposed patch we can miss some initialization. 4.) === Why patch contain ltdl.{h|c} and xmlsec-ltdl.{h|c|c.patch} ? Where/What is problem in original ltdl ?
1) You are right, it;s not necessary :) But just in case :) 2) and 3) Yes, it's possible that one crypto engine implements, say, AES and another one does not. But application can detect it (corresponding klass would be NULL) or we would fail as soon as application would try to use it (thanks to xmlSecAsserts). It's perfectly legal to have NULLs in the functions table. Again, not all crypto engines are the same. Some have the functionality that is not implemented by others. There is no need to worry about that. The purpose of XMLSEC_NO_AES (and friends) is to disable the particular feature all together. For example, in embedded case you might have limited memory size. Thus you might want to disable some features to reduce xmlsec library size. 4) Suppose you have another library XYZ that also embeds ltdl.c file. Now you want to link library XYZ and xmlsec in one application. Guess what? You'll have a symbols conflict because for example lt_open is defined and implemented in both libraries.
Created attachment 19848 [details] [review] DL implementation for Windows (native,not ltdl based; patch for both trunk and branch)
undefined symbols: In version xmlsec-20030916(CVS) libxmssec1.so has undefined symbols. Use on linux "ldd -r ../src/.libs/libxmlsec1.so" to see. LTDL_PARSE or xmlsec-ltdl.patch should change these symbols too. Result is that I cannot link my test samples. Note: xmlsec1 examples are not tested, but they should fail too.
Created attachment 19976 [details] [review] link xmlsec core library with dl libraries
No, the xmlsec tests do not fail because I use "pkg-config" that provides correct linker flags (i.e. it includes the required "-ldl"). Anyway, good catch! The trivial fix is attached and checked into both trunk and branch.
I feel that we can declare this bug closed. Any new problems with dynamic loading should be reported as separate bugs.