Hi Martin On 09.04.2010 12:15, Martin Bartosch wrote: > Determining the installed software version at runtime can be done with > something similar to > > perl -e 'use OpenXPKI::VERSION; print $OpenXPKI::VERSION::VERSION' > > but this only works if OpenXPKI was built properly. I found that sometimes > (depending on build process and packaging) this information may > not be accurate. We could add an API function to get > this version number, of course. > > Reporting the package version is a different thing, it's highly > dependent on the target system distribution, and I don't think we can > find a canonical way to determine package versions regardless of system > type. It will not work on systems where OpenXPKI was not installed > via a package manager, as well.
Yes. Seems that this "about" problem should be the last in the todo list, but should be there anyway. Spent quite some time reading websvn. Seems that the idea to roll back last year is unsatisfactory. Suggest to forget it. Freebsd project is rapidly moving everything to openssl-1. Today it has openssl-0.9.7 or openssl-0.9.8 installed as a part of the base system (different branches of freebsd has different versions of openssl here). Instead of the base openssl, a user can choose to install openssl-1 from ports (ie from package) on any freebsd branch. Hence openssl-0.9.8 is not available at all in some branches. (Assume today nobody installs anything by hand.) My attempt to persuade freebsd people to keep openssl-0.9.8 as a separate port failed, despite the fact that many other ports are reported been incompatible with openssl-1. openssl-1 deliberatly neglects backward compatibility with openssl-0.9.8. That is why I had to declare a freebsd collection of openxpki related ports as "broken" for certain branches of freebsd, and "incompatible" with many modern installations which have openssl-1 installed. As of the OpenXPKI, the problems related to openssl-1 are as follows: - naive checks of openssl version which assume version to begin with a string "0.9." - implicit assumption about low-level data types declared in openssl, which have changed in openssl-1. This is not related to cryptography. - calls to low-level functions that vanished or changed in openssl-1. This is not related to cryptography. - different approach to deal with cryptography, which is very similar to our cryptography abstraction concept. So let us answer questions about our future tactics. Let us forget about non-western cryptography for a while. 1. Shall we just migrate to openssl-1 abandoning support for openssl-0.9.8, or shall we support both versions of openssl? Support of both versions simultaneously just in a xs code could be very hard, because openssl heavily uses preprocessor stage redefinition of data types, with which it is not easy to cope when programming in xs instead of plain c. 2. Shall we try to prepare a new cryptographic backend called openssl-1, in addition to existing backend called openssl-0.9.8? This would justify our old claim http://www.openxpki.org/docs/crypto-plug.html that we are ready to add new separate cryptographic layers, and will retain support for openssl-0.9.8 in a more beautiful fashion. This approach will require some code fixing to return to cryptographic modularity concept though. And could buy us extra bonus returning the non western cryptography a sort of automatically. Regards, Sergei ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
