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
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
