
<html><head></head><body>Let's not overlook the simple fact that a lot of deployments are behind secure firewalls, on secure networks, and on servers and lans that no users have access to (physical ormotherwise), and thus have negligible security requirements beyond what the environment already provides. Yes, the more advanced stuff may have validity and use some places, but the ability to stand up nut without that added layer of complexity has a lot of value as well . . . <br><br>(I run one of those environments, and frankly, would likely instantly cease to upgrade of all this was rammed down my throat and not a choice. The idiotic deliberate breakage of Java in that many older systems can no longer have a functional network console, even on a secure network, is the perfect example of what *NOT* to do!) The end user should *ALWAYS* have the choice - never a mandate!<br><br><br><div class="gmail_quote">On June 13, 2021 11:06:35 AM CDT, Manuel Wolfshant <wolfy@nobugconsulting.ro> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre dir="auto" class="k9mail">On 6/13/21 3:36 PM, Jim Klimov via Nut-upsdev wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Haven't got many ideas on this today, preoccupied with other <br> house-work, but can share a couple :)<br><br> Regarding two implementations - I believe NSS and OpenSSL are licensed <br> differently and/or are (initially were?) available non-overlapping on <br> different OSes. A quick googling now showed that they both were <br> actually provided under different licenses over different releases and <br> years.<br><br> As long as NUT consumes "some way to secure the packets" and does not <br> really care what that way is, leaching onto one or another library was <br> a decent choice (and better than using just one and offering nothing <br> on platforms that do not support it).<br><br> I *think* the different ways of configuration apply to some features <br> only supported by (integration with?) one of those libraries, but <br> can't vouch for that OTOH :)<br><br> Regarding self-signed certs vs. private (corporate) CA vs. commercial <br> - technically they are all the same, politics and setup policies and <br> responsibilities differ. Back in my sys-admining days, we had a <br> private CA with in-house scripting for openssl for engineering gear <br> (UPSes, PDUs, IPMIs and equivalents) which gave some measure of <br> security (encrypted comms) for many devices with some ease of setup <br> (one cert - engCA - to add trust for in a browser or similar client).<br><br> Having an easy self-signed secure setup for small deployments (e.g. <br> home LAN) is certainly a welcome bonus - when several computers are <br> protected by one UPS and one upsd, but I'd expect (maybe biased) that <br> any sort of small office or larger deployment with more than a couple <br> of NUT clients and/or servers would go for a centralized cert setup. <br> It is not too hard to conjure up, with many free and commercial tools <br> available to orchestrate depending on the scale they would need.<br><br> As for listening on several interfaces and/or ports from a single upsd <br> instance, can't quickly check, so would fathom a guess that NUT <br> codebase did not have a reason to bother yet to support that. <br> Otherwise, your points (4) and (5) make sense and are "doable" <br> generally, after some effort :)<br></blockquote><br>1. There are miriad of scripts written on top of openssl and certutil <br>that allow implementing a CA and issuance of certificates, with easy-rsa <br>probably leading the lot (and usage basically consists of running <br>./build-ca followed by ./build-key ( for v2 ) and equivalent parameters <br>passed to the only script that easy-rsa v3 consists of ). Even f-droid <br>provides one for android, if I am not mistaken. I really do not see the <br>need for yet another set of scripts that reimplement the wheel, <br>especially as the existing programs provide a full stack of tools <br>implementing all the stages a certificate can have, from creating a CA <br>to revoking a certificate.<br><br>2. nut can be very nicely wrapped behind stunnel if a point to point <br>connection between master and slaves is needed. Other tools also exist, <br>are reliable and well known, tested and vetted. Therefore, from my point <br>of view, even if the python shim approach is smart and nice, I do not <br>see it as being really needed. A link to stunnel and an example included <br>in the docs would do just as well. With all due respect, the shim idea <br>looks to me like a "not invented here" approach. To be clear: I am not <br>opposed to it but I would certainly not use it when "yum install stunnel <br>/ apt install stunnel" are available.<br><br>3. Last but not least, for anyone with low to moderate knowledge, <br>letsencrypt takes minutes to setup and use and has the advantage of not <br>requiring anything but running their script every 3 months.<br><br><br>wolfy<hr>Nut-upsdev mailing list<br>Nut-upsdev@alioth-lists.debian.net<br><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br></pre></blockquote></div><div style='white-space: pre-wrap'><div class='k9mail-signature'>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></body></html>