<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 6/13/21 10:13 PM, Jim Klimov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJYg8vJVDD4u3fYicgL88ebP7RcSm0gGCfAiu3dgJjAOzXcm_g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<span class="gmail-im">>>The idiotic deliberate breakage
of Java in that many older<br>
>>systems can no longer have a functional network
console, even on a<br>
>>secure network, is the perfect example of what *NOT*
to do!)<br>
</span>
<div>
>Incidentally I fight for 2 weeks trying to obtain again
control over an IBM chassis which requires an old Java<span
class="gmail-im"></span></div>
<div><span class="gmail-im">
<br>
</span></div>
<div><span class="gmail-im">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..." <br>
</span></div>
<div><span class="gmail-im">IIRC, some time around jdk-1.6.37
could be one of the pivot points for that.<br>
</span></div>
</div>
</blockquote>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJYg8vJVDD4u3fYicgL88ebP7RcSm0gGCfAiu3dgJjAOzXcm_g@mail.gmail.com">
<div dir="ltr">
<div><span class="gmail-im"><br>
</span></div>
<div><span class="gmail-im">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.<br>
</span></div>
<div><span class="gmail-im"><br>
</span></div>
<div><span class="gmail-im">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.</span></div>
</div>
</blockquote>
<p>As a guy doing security stuff for 20+ years and having several
audits yearly, I feel you.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJYg8vJVDD4u3fYicgL88ebP7RcSm0gGCfAiu3dgJjAOzXcm_g@mail.gmail.com">
<div dir="ltr">
<div><span class="gmail-im"> 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.</span></div>
</div>
</blockquote>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJYg8vJVDD4u3fYicgL88ebP7RcSm0gGCfAiu3dgJjAOzXcm_g@mail.gmail.com">
<div dir="ltr">
<div><span class="gmail-im"> But setup becomes more
complicated...</span></div>
</div>
</blockquote>
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.<br>
</body>
</html>