[xmlsec] build system changes

[Aleksey Sanin]

>  What about crypto lib to be loaded dynamically, i.e. xmlsec core to 
> have "plugin architecture"?

If you really want to do it then you can do it already. I don't want to 
go into "plugin" bussiness myself
because (IMHO):
    - The main usage for xmlsec is on servers, most likely there would 
be only one crypto
    engine and nobody cares about plugins.
    - It would be difficult to maintain (different OS have different 
ways of loading shared libs).
    - I don't think it's a good idea from security point of view to load 
crypto engines as plugins.

I would love to see a use case when application would need to switch 
crypot libraries "on the fly".
IMHO, crypto library is something you "just use" (of course, unless you 
are an author of that library :) ).

> About packages ... 

Ok, may be I was not clear about proposed changes. I would like to try 
to explain again.
I want to:
    1) Always build all available xmlsec-<crypto> libraries (it's not 
the case on windows).
    I hope the reaso.ns for that change are clear.
    2) Always build all xmlsec-<crypto> command line tools and do a soft 
link or copy
    of the xmlsec-<default-crypto>(.exe) to xmlsec(.exe). This would 
make everything backward
    compatible and in the same time will provide an abillity to use, 
say, xmlsec-openssl.exe
    to test xmlsec-mscrypto.exe and produce both during one build. This 
is also required for
    next step.
    3) Split current xmlsec and xmlsec-devel RPM packages into xmlsec, 
xmlsec-devel,
    xmlsec-openssl, xmlsec-openssl-devel. The reasons for that is that I 
would like to have a more
    symmetrical system. I.e. we already have xmlsec-nss and 
xmlsec-nss-devel and
    it's strange that there is no xmlsec-openssl and 
xmlsec-openssl-devel. Also this would
    give an NSS use who does not want to know about OpenSSL a way to use 
xmlsec
    w/o installing OpenSSL.

None of the changes above has any API or ABI modifications (except may 
be the last one:
a user who installed just xmlsec packaged now would have to install 
xmlsec and xmlsec-openssl).

> May be we should have some wrappers as example for certificate: 

I don't want to make xmlsec a wrapper for crypto engines. My goal was to 
create common API
for dealing with XML Security related stuff. For example, inside core 
xmlsec I don't care how the
application/crypto library stores the key. I am only interested in 
having non-null xmlSecKeyPtr :)

And I don't think it is really possible to find a simple and nice way to 
wrap different crypto libs in
one API. Take a look at OpenSSL, NSS and MSCrypto APIs for dealing with 
X509 certs store.
IMHO, mapping all of them into one common API is not a simple task and 
one would always find
a reason to go and use native functions. For example, I am familiar with 
a big cross-platform
client application that is based on a wxWindows library (which provides 
unified wrapper API for
native GUI for Windows, Mac, GNOME/GTK, etc). wxWindows is a great 
library and it has
everything needed for writing a cross-platform GUI code. Unfortunately, 
this application  still have
a lot of "#ifdef WX_WINDOWS" or "#ifdef WX_MAC" conditions because
 - only Windows have registry and COM objects;
 - Mac hides files starting with dot (".xxx") and user has no easy way 
to access them;
 - in GTK/GNOME only one thread can do GUI;
 ...
The list is huge and I would guess that total "common" GUI code in that 
application is not more
than 60% of all GUI code. This is a great result that shows how 
wxWindows simplify writing
cross-platform applications but it also shows that even very 
sofisticated and complex "common
API wrapper" has its limitations.


Aleksey