Nut upsdev - Sep 2022 - Fwd: [networkupstools/nut] Hide 'Init SSL without certificate database' message for upsc (PR #1662)

Hello all,

  Here's a PR I want to ask community about: should NUT clients like upsc
report (log!) or hide the infamous 'Init SSL without certificate
database'
message?

  On one hand, it is a reminder that the setup is insecure (plaintext
protocol, might be in an externally provided tunnel but we don't know
that). On another, it is fairly annoying and if it does clutter
syslog/journal from cron jobs etc. - is also somewhat toxic (causes I/O,
uses space) if deployment owner is not going to do anything about it anyway
for whatever reason (LAN, VPN, SSH tunnel...).

  That PR proposes to hide the message by default, with debug level 1. One
alternative is to use debug level 0 so it always pops up on stderr like
now, but does not hit the syslog.

  WDYT?

  If nobody vetoes it strongly, I plan to merge it in say a week.

Jim

---------- Forwarded message ---------
From: tofurky <notifications at github.com>
Date: Fri, Sep 16, 2022, 01:07
Subject: [networkupstools/nut] Hide 'Init SSL without certificate
database'
message for upsc (PR #1662)
To: networkupstools/nut <nut at noreply.github.com>
Cc: Subscribed <subscribed at noreply.github.com>


This can clutter up logs on things that call 'upsc', such as Munin
plugins.
Switch it to upsdebugx() so it's not always output to stderr.
------------------------------
You can view, comment on, or merge this pull request online at:

  https://github.com/networkupstools/nut/pull/1662
Commit Summary

   - 613185d
  
<https://github.com/networkupstools/nut/pull/1662/commits/613185d4be1240531f46c60f870a2c219ca435b7>
   Hide 'Init SSL without certificate database' message for upsc

File Changes

(1 file <https://github.com/networkupstools/nut/pull/1662/files>)

   - *M* clients/upsclient.c
  
<https://github.com/networkupstools/nut/pull/1662/files#diff-821fd001277fb11e909bb718c7412b6086321d302ced2868a777c28e61442855>
   (4)

Patch Links:

   - https://github.com/networkupstools/nut/pull/1662.patch
   - https://github.com/networkupstools/nut/pull/1662.diff

?
Reply to this email directly, view it on GitHub
<https://github.com/networkupstools/nut/pull/1662>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFBHVWPFOMGUZFWVB3LV6OT3RANCNFSM6AAAAAAQN2WRTQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: <networkupstools/nut/pull/1662 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220916/ffdfb64f/attachment.htm>

On Fri, 16 Sep 2022, Jim Klimov via Nut-upsdev wrote:
> Hello all,
> ? Here's a PR I want to ask community about: should NUT clients like
upsc report (log!) or hide the infamous 'Init SSL without certificate
> database' message?
> 
> ? On one hand, it is a reminder that the setup is insecure (plaintext
protocol, might be in an externally provided tunnel but we don't
> know that). On another, it is fairly annoying and if it does clutter
syslog/journal from cron jobs etc. - is also somewhat toxic (causes
> I/O, uses space) if deployment owner is not going to do anything about it
anyway for whatever reason (LAN, VPN, SSH tunnel...).
> 
> ? That PR proposes to hide the message by default, with debug level 1. One
alternative is to use debug level 0 so it always pops up on
> stderr like now, but does not hit the syslog.
It seems to me that the alternative, to use debug level 0 so that the message 
always appears on stderr but does not go to syslog, is the best compromise.

In modern times, plain text transmission is a weakness which should not be 
ignored.  If there is an external solution in place, e.g. a tunnel, then the 
call to upsc should accompanied by 2>/dev/null.

Currently the man page does not mention the stderr message.  Perhaps it should, 
together with a suggestion to use 2>/dev/null if the message is not relevant.

The reference to "SSL" could be replaced by "TLS".  All SSL
protocols are now
deprecated (as are TLS 1.0 and 1.1).

Roger

On Fri, 16 Sep 2022, Jim Klimov via Nut-upsuser wrote:
> Hello all,
> ? Here's a PR I want to ask community about: should NUT clients like
upsc report (log!) or hide the infamous 'Init SSL without certificate
> database' message?
> 
> ? On one hand, it is a reminder that the setup is insecure (plaintext
protocol, might be in an externally provided tunnel but we don't
> know that). On another, it is fairly annoying and if it does clutter
syslog/journal from cron jobs etc. - is also somewhat toxic (causes
> I/O, uses space) if deployment owner is not going to do anything about it
anyway for whatever reason (LAN, VPN, SSH tunnel...).
> 
> ? That PR proposes to hide the message by default, with debug level 1. One
alternative is to use debug level 0 so it always pops up on
> stderr like now, but does not hit the syslog.
It seems to me that the alternative, to use debug level 0 so that the message 
always appears on stderr but does not go to syslog, is the best compromise.

In modern times, plain text transmission is a weakness which should not be 
ignored.  If there is an external solution in place, e.g. a tunnel, then the 
call to upsc should accompanied by 2>/dev/null.

Currently the man page does not mention the stderr message.  Perhaps it should, 
together with a suggestion to use 2>/dev/null if the message is not relevant.

The reference to "SSL" could be replaced by "TLS".  All SSL
protocols are now
deprecated (as are TLS 1.0 and 1.1).

Roger

On Fri, 16 Sep 2022, Jim Klimov via Nut-upsuser wrote:
> Hello all,
> ? Here's a PR I want to ask community about: should NUT clients like
upsc report (log!) or hide the infamous 'Init SSL without certificate
> database' message?
How should upsc be used in order to get SSL/TLS protection?  There is no 
configuration file with a CERTFILE declaration.  Is there some other way to say 
where the public key certificate is?

Perhaps the man page should explain this.

Roger

I don't know whether the message would appear in my case, but I would be
annoyed if someone tried to urge me to encrypt a connection that is only ever
made on localhost (a packet filter blocking access from elsewhere).
So in case it would appear in my case, I would need an option to make it
disappear (or I would probably patch it away locally).