On 6/13/21 10:13 PM, Jim Klimov wrote:
>>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
My condolences. It usually went along the lines of "fire up a VM with
a 10-year old distro, (find and) install Java 5 or 6..."
IIRC, some time around jdk-1.6.37 could be one of the pivot points for
that.
Yeah, I tried linux and windows ( CentOS 6 & W10 ) with all the
combinations of firefox 52.8 ESR, 52.9 ESR, jre 1.6.32 , jre 1.6.45 and
openjdk. Only linux+openjdk barely works but it is unusable because it
sends a random number of keypresses each time I press any single key.
Other combinations just trigger errors or display blank pages. The most
frustrating thing is that I have a special VM with C6 which _worked_
until a few months ago and I'll be damned if I know what did I do to
break it. Because I am pretty sure _I_ broke it... somehow.
Thanks for raising this point, a pain like this is indeed not
something we would want to force on all NUT users, maybe not even by
default, and it is worth keeping that in mind.
On another hand, more and more laws (like, real-life legislation) and
by-laws (like, IETF asking "how do you secure your comms before we
take your protocol for publishing?") tend to require us as a community
to at least offer something in this regard.
As a guy doing security stuff for 20+ years and having several audits
yearly, I feel you.
And as mentioned earlier in the discussion, maybe it is best
"outsourced" from NUT codebase (or at least NUT makes it easy to
outsource, such as with stunnel or shims that Roger proposed), so that
"modern du jour" crypto protection of NUT protocol on the wire
(including loopback for those inclined) can evolve at a different pace
from NUT releases. If only crypto libs evolved as just drop-in
replacements, without API and ABI changes... Notably, things like
stunnel do just that - as far as NUT is concerned, there is a
black-box pipe to send some bytes to and get some back.
I still believe in the original linux concept of KISS and writing
programs which can do as well as possible the fewest number of things
possible and then daisy chain the tools as needed ( just as Roger
implemented the shim but that ssh -L and stunnel already do ). Rather
than making nut more complex in an area which is not its selling point,
I find it better to develop the UPS drivers and delegate the encryption
/ protection to the tools dedicated for this purpose.
But setup becomes more complicated...
The moment you want security on top of almost anything, things become
more complicated. Frankly nothing comes to mind that does not require at
least ticking an additional button somewhere to switch between security
models. Even if sometimes the clients hide the complexity ( like
browsers which default to attempting to use https and things becoming
funny when the servers reply with different content of http and https ),
it is there. I am on IRC almost daily since 1994 and I still have to
tick "this network uses SSL" when doing the initial configuration.
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
