[th/libnm-crypto] move crypto code to separate static library and cleanup uses/dependencies
We have nm-crypto.h"` which is internal API (and abstracts a crypto backend like gnutls, nss or null).
That code is used by libnm-core-impl, thus both the daemon and libnm.so drag in the crypto dependencies.
I wanted to better understand where/how we use this, even with the hope that we ever could drop them. Or maybe only dlopen() on demand? I also wanted to better understand when the client reads certificate files (which is the purpose of why we have the crypto code in first place).
- move the code to a new static library (
src/libnm-crypto) - rework the code so that libnm-crypto no longer depends on libnm-core-impl (but the other way the dependency is obviously still there).Previously our crypto code had itself dependencies on libnm-core-impl.
- move some of the crypto usage from
src/libnm-core-impl/nm-utils.ctosrc/libnm-client-impl/nm-libnm-utils.c. This code is only used as part of the public API of libnm, not by the daemon. This move is done to make that clearer (and not accidentally start using them -- because, unlike libnm-crypto, the don't have a clear name that shows "this is crypto code").
The entire point is that the crypto dependency is heavy, and we should be clear about where we use it.
as to the main goal (of dropping crypto dependency altogether). That is gonna be hard. The main user is nm-setting-8021x.c (see git grep include.*libnm-crypto) and there it's kinda necessary.
This is related to the "drop CAP_DAC_OVERRIDE capability" effort. It also shows that NM is reading those certificate files (and thus quite possibly needs DAC_OVERRIDE to access the file in e.g. ~/.cert. It's also gonna be hard to do that via nm-priv-helper, because the code currently is synchronous. Checking the certificates via D-Bus (by asking nm-priv-helper) would require to make the usage asynchronous.
TL;DR: I think this structures our crypto code better and makes it's usage easier to understand.