[OpenWrt-Devel] SSL/TLS crypto library headaches

Daniel Golle daniel at makrotopia.org
Sun Jun 28 17:37:28 EDT 2015

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
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
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

I'd appreciate to be pointed at any previous discussion on that topic
and would like to know the opinion of other developers.



 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 at lists.openwrt.org

More information about the openwrt-devel mailing list