On June 13, 2021 9:02:46 PM GMT+03:00, Tim Dawson <[email protected]> wrote: >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 . . . Absolutely correct.
> >(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. Same here >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!) Incidentally I fight for 2 weeks trying to obtain again control over an IBM chassis which requires an old Java > The end >user should *ALWAYS* have the choice - never a mandate! > My thoughts exactly ! Thank you for phrasing it out loud, Tim. > >On June 13, 2021 11:06:35 AM CDT, Manuel Wolfshant ><[email protected]> wrote: >>On 6/13/21 3:36 PM, Jim Klimov via Nut-upsdev wrote: >>> Haven't got many ideas on this today, preoccupied with other >>> house-work, but can share a couple :) >>> >>> Regarding two implementations - I believe NSS and OpenSSL are >licensed >>> differently and/or are (initially were?) available non-overlapping >on >>> different OSes. A quick googling now showed that they both were >>> actually provided under different licenses over different releases >and >>> years. >>> >>> As long as NUT consumes "some way to secure the packets" and does >not >>> really care what that way is, leaching onto one or another library >was >>> a decent choice (and better than using just one and offering nothing > >>> on platforms that do not support it). >>> >>> I *think* the different ways of configuration apply to some features > >>> only supported by (integration with?) one of those libraries, but >>> can't vouch for that OTOH :) >>> >>> Regarding self-signed certs vs. private (corporate) CA vs. >commercial >>> - technically they are all the same, politics and setup policies and > >>> responsibilities differ. Back in my sys-admining days, we had a >>> private CA with in-house scripting for openssl for engineering gear >>> (UPSes, PDUs, IPMIs and equivalents) which gave some measure of >>> security (encrypted comms) for many devices with some ease of setup >>> (one cert - engCA - to add trust for in a browser or similar >client). >>> >>> Having an easy self-signed secure setup for small deployments (e.g. >>> home LAN) is certainly a welcome bonus - when several computers are >>> protected by one UPS and one upsd, but I'd expect (maybe biased) >that >>> any sort of small office or larger deployment with more than a >couple >>> of NUT clients and/or servers would go for a centralized cert setup. > >>> It is not too hard to conjure up, with many free and commercial >tools >>> available to orchestrate depending on the scale they would need. >>> >>> As for listening on several interfaces and/or ports from a single >upsd >>> instance, can't quickly check, so would fathom a guess that NUT >>> codebase did not have a reason to bother yet to support that. >>> Otherwise, your points (4) and (5) make sense and are "doable" >>> generally, after some effort :) >> >>1. There are miriad of scripts written on top of openssl and certutil >>that allow implementing a CA and issuance of certificates, with >easy-rsa >>probably leading the lot (and usage basically consists of running >>./build-ca followed by ./build-key ( for v2 ) and equivalent >parameters >>passed to the only script that easy-rsa v3 consists of ). Even f-droid > >>provides one for android, if I am not mistaken. I really do not see >the >>need for yet another set of scripts that reimplement the wheel, >>especially as the existing programs provide a full stack of tools >>implementing all the stages a certificate can have, from creating a CA > >>to revoking a certificate. >> >>2. nut can be very nicely wrapped behind stunnel if a point to point >>connection between master and slaves is needed. Other tools also >exist, >>are reliable and well known, tested and vetted. Therefore, from my >point >>of view, even if the python shim approach is smart and nice, I do not >>see it as being really needed. A link to stunnel and an example >included >>in the docs would do just as well. With all due respect, the shim idea > >>looks to me like a "not invented here" approach. To be clear: I am not > >>opposed to it but I would certainly not use it when "yum install >stunnel >>/ apt install stunnel" are available. >> >>3. Last but not least, for anyone with low to moderate knowledge, >>letsencrypt takes minutes to setup and use and has the advantage of >not >>requiring anything but running their script every 3 months. >> >> >>wolfy _______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
