Small devices should be running without the dbengine. The netdata instances on those devices should be streaming metrics to other netdata for long-term storage. @paulkatsoulakis on that sheet we have in #6300 we should also mention how one could remove a particular dependency, when they don't want the installation to include it. We already have several such flags, we may need to add more.

The other TLS libraries do make sense for the SSL support though, so we should do the work anyway.

Unless I'm mistaken, the dbengine is completely independent of OpenSSL. If it isn't, it should be, as it isn't doing any encryption.

As far as alternate TLS implementations, mbed should indeed be on the list, and I'd argue that verifying against LibreSSL should be there too (I'm 99% certain from a quick look at what we're using that LibreSSL will work (provided of course that the headers match up properly), but having some level of official support would be good). GnuTLS and NSS would be nice to have in terms of flexibility, but not critical. Also, if we're looking at Windows support, we should probably eventually support SChannel (the TLS implementation provided as part of Windows).

Unless I'm mistaken, the dbengine is completely independent of OpenSSL. If it isn't, it should be, as it isn't doing any encryption.

It's just using the cryptographic SHA functions.

@mfundul OK, potentially stupid question: Why are we using a crypto hash for a non-cryptographic purpose? I mean, I would assume we're using it as part of some sort of hash table structure, or for integrity checking the files on disk when we load them, both of which don't need crypto-grade hashes.

@mfundul OK, potentially stupid question: Why are we using a crypto hash for a non-cryptographic purpose? I mean, I would assume we're using it as part of some sort of hash table structure, or for integrity checking the files on disk when we load them, both of which don't need crypto-grade hashes.

For the same reason it's used in deduplication solutions, to guarantee practically no collisions for deterministic UUID generation.

edit: we use CRC32 for integrity checking

Ah, OK, I didn't realize we were using UUID's internally in the dbengine backend.

Might be worth considering the option of just using libuuid on Linux systems for that, as that would allow people to build Netdata on Linux without it depending on any SSL/TLS library.

Ah, OK, I didn't realize we were using UUID's internally in the dbengine backend.

Might be worth considering the option of just using libuuid on Linux systems for that, as that would allow people to build Netdata on Linux without it depending on any SSL/TLS library.

That is the plan for the current design, but until we put some data structures in place (e.g. metrics map) to handle random UUIDs we are stuck with uniquely mapping netdata chart/dimension identifiers to UUIDs.

In any case, dbengine is not a hard requirement to compile the actual code itself. ./configure should proceed without problems without dbengine dependencies and it should produce a binary with no dbengine support.

It can even be explicitly ran like this ./configure --disable-dbengine.

Moreover, dbengine is kind of useless in small devices without storage.

I think there was no change since I reported this issue, right? OpenWrt is now using WolfSSL by default instead of MbedTLS and would be good if there is support for it as well instead of relying only on OpenSSL.

There was some work for LibreSSL done by @Ferroin but unsure about others.

There was some work for LibreSSL done by @Ferroin but unsure about others.

Actually it was @thiagoftsm who did the LibreSSL stuff.

I absolutely agree though that we need better support for a wider variety of TLS implementations. At minimum WolfSSL, but ideally probably also GNUTLS and MbedTLS as well.

LibreSSL was a small problem already fixed.

For the other TLS libraries, I agree with @Ferroin it is a feature that we need to work, probably we already have all basis to do this.

@dim08, please, let us add a workaround for this.

@thiagoftsm please do so

Hello everybody,

I made the PR that will bring support for WolfSSL, but I observed that when libwebsockets is compiled against WolfSSL, it does not recognize some functions that WolfSSL has, this means that the cloud is a function that is not available when it is used. 😞

I will take a look later to verify if a patch to libwebsockets can fix this problem.

Best regards!

@thiagoftsm we are planning the ACLK-NG that will not need libwebsockets.

@thiagoftsm we are planning the ACLK-NG that will not need libwebsockets.

Thanks for the update @underhood ! I won't expend time trying to fix the wolfssl compilation against libwebsockets considering that we won't need it.

With PR #15113 we re-wrote and abstracted the entire SSL support in netdata. Using the new code, it is much easier to have different ssl implementations in Netdata.