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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210614/fbbfebc7/attachment-0001.htm>