Following up from issue #3331 - currently NUT builds select one of SSL backends (or none), both for server and libupsclient sides.
This issue proposes to restructure the code to be able to optionally (important, due to licensing requirements on some distros' packaging!) configure a NUT build with both backends to be available at once, and the choice of using OpenSSL setup with PEM files or NSS setup with certificate databases to be done at run-time for each NUT deployment. This way, for OSes (or custom builds) that find licensing of both OpenSSL and Mozilla NSS acceptable, the same build of NUT can be used to enjoy (or test) the capabilities resented by either code path.
Note this change is likely to impact packaging recipes, at least on distros that do choose to ship both capability sets in the same build (so a nut-server and libupsclient with its dependents would pull in both SSL backend libraries for dynamic linking).
Conversely, by default this solution should not introduce surprises for existing builds. Probably the easiest way to enable such route would be to have ./configure --with-nss --with-openssl specified explicitly at the same time, and ./configure --with-ssl to keep playing preferences as it does now.
This would also simplify the NUT CI farm load by having less build scenarios to test that both code paths are valid for compilation.
Building upon #1711 solution in #3330, the NIT suite could test several such already-built setups (maybe even cross-capability of NSS server and OpenSSL client and vice versa), whether in a whole matrix approach or choosing a combo randomly like the quicker non-deterministic approach in ci_build.sh does now to test various SSL and USB backends, etc. In some way, this issue is also related to #1242.
Following up from issue #3331 - currently NUT builds select one of SSL backends (or none), both for server and
libupsclientsides.This issue proposes to restructure the code to be able to optionally (important, due to licensing requirements on some distros' packaging!)
configurea NUT build with both backends to be available at once, and the choice of using OpenSSL setup with PEM files or NSS setup with certificate databases to be done at run-time for each NUT deployment. This way, for OSes (or custom builds) that find licensing of both OpenSSL and Mozilla NSS acceptable, the same build of NUT can be used to enjoy (or test) the capabilities resented by either code path.Note this change is likely to impact packaging recipes, at least on distros that do choose to ship both capability sets in the same build (so a
nut-serverandlibupsclientwith its dependents would pull in both SSL backend libraries for dynamic linking).Conversely, by default this solution should not introduce surprises for existing builds. Probably the easiest way to enable such route would be to have
./configure --with-nss --with-opensslspecified explicitly at the same time, and./configure --with-sslto keep playing preferences as it does now.This would also simplify the NUT CI farm load by having less build scenarios to test that both code paths are valid for compilation.
Building upon #1711 solution in #3330, the NIT suite could test several such already-built setups (maybe even cross-capability of NSS server and OpenSSL client and vice versa), whether in a whole matrix approach or choosing a combo randomly like the quicker non-deterministic approach in
ci_build.shdoes now to test various SSL and USB backends, etc. In some way, this issue is also related to #1242.