Hi everybody! I believe we all agree that the world is a mess. Thus it's not very surprising that the currente state of crypto- libraries *and their packaging* is just as messy as everything else. However, especially in case of those libraries, one might want to be very careful and choose a single system-wide implementation and configuration. In OpenWrt we currently favour mbedTLS/PolarSSL but also provide cyassl, OpenSSL and GnuTLS. As most packages need to be linked against one specific library at build time, this is either configurable in the build system (like for curl, see [1]) or provide several build variants, one foreach crypto- backend supported by the package (like ustream-ssl, see [2]). Using build-variants is feasible in case the number of variants is low enough to maintain. In case of curl, which allows the selection of various features at compile time, that would result in v = 2^f * t where v is the total number of build-variants, f the number of boolean feature decissions (enable/disable) and t the number of supported crypto-libraries. Most likely not all combinations will result in a successful build or usable binaries... In either way, packages making use of libraries (like libcurl or libustream-ssl) will either have to accept build-time choices made for those libraries (like in case of libcurl) or select a specific variant to depend on (like in case of libustream-polarssl) and maybe by itself provide variants of the package for each upstream cryptolib available (like uhttpd does, see [3]).
I thus suggest to fix the mess by selecting a *single* implementation at build-time, similar to how we allow different C++ standard libraries to be selected, see [4]. In that way, packages can depend on $(TLS_DEPENDS) and provide some ifdefery around CONFIG_USE_MBEDTLS, CONFIG_USE_GNUTLS, ... It's notable that this would also allow to build most packages made to be linked with OpenSSL against libgnutls-openssl without having to change sources as GnuTLS provides some drop-in headers for source-level compatibility with OpenSSL. An alternative may be to provide automatic packaging templates and allow packages to declare which crypto-backends they support and auto-generate variants as well as CONFIGURE_ARGS, ... and templates for packages making use of them further downstream on the dependency graph. I'd appreciate to be pointed at any previous discussion on that topic and would like to know the opinion of other developers. Cheers Daniel 1: https://dev.openwrt.org/browser/trunk/package/network/utils/curl/Config.in 2: https://dev.openwrt.org/browser/trunk/package/libs/ustream-ssl/Makefile 3: https://dev.openwrt.org/browser/trunk/package/network/services/uhttpd/Makefile#L65 4: https://dev.openwrt.org/browser/trunk/include/uclibc%2B%2B.mk#L8 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
