So it sounds to me like we would rather keep the existing noisy behavior by default? (Assuming clients in fact have/get a way to specify a certdb and avoid the message validly?)
Would it be acceptable then to add a (non-default) CLI/envvar option to hush this one message? Like "yes I'm shooting meself in da foot, don't keep reminding"? Looking a bit more in the code context, NSS is initialized anyway if built-in, just without a (custom... hmm, should try system?) certdb. Jim On Fri, Sep 16, 2022, 16:58 Manuel Wolfshant via Nut-upsdev < [email protected]> wrote: > > > On September 16, 2022 11:08:09 AM GMT+03:00, Roger Price < > [email protected]> wrote: > >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). > > > > > +1 to all of Roger's suggestions > > wolfy > >Roger > > _______________________________________________ > Nut-upsdev mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
