[xmlsec] build system changes
aleksey at aleksey.com
Fri Sep 5 01:09:19 PDT 2003
> 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
- 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,
to test xmlsec-mscrypto.exe and produce both during one build. This
is also required for
3) Split current xmlsec and xmlsec-devel RPM packages into xmlsec,
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
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
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.
More information about the xmlsec