Attempt to fix issue #680

This probably will need some llvm or other exceptional handling for
non GNU build systems.

Since we're logging at INFO level when the connect is attempted, we can assume
success when we start logging additional init messages.

These can always be revived from the attic if there's some need or purpose.

My mail server was suddenly and inexplicably creating thousands of SMTPS
client threads, each with a unique remote IP address, and each eventually
failing with the rather obscure log message (from cryptlib):
 dbg 'Cannot read item from object' (-41) setting session active

Eventually (after not long, really), the server would run out of resources
and fail in weird and wonderful ways (can't malloc, can't create JS runtime
or context, etc.). The max_clients limit (100, as I have it set) wasn't being
effectively-imposed on SMTPS connections.

The root-cause: the active_clients (counter) wasn't incremented until *after*
the cryptlib/TLS setup for SMTPS connections and SMTPS/TLS connections can
take a long time to fail, resulting in a vulnerability to an effective denial
of service attack.

Raise the minimum severity of all cryptlib/TLS log messages from Debug to
Info.

Create wrappers for smtp_thread() [now smtp_client_thread()] and pop3_thread
[now pop3_client_thread()] that handle basic resource management (thread
counters, active client counters, the client socket).

... in malloc error reporting messages

We need to call mqtt_shutdown() instead of mqtt_close() to have the mosquitto
(loop) thread stopped.

Upon connect failure, call the mqtt_shutdown() *before* calling lprintf->lputs,
which would eventually try to MQTT-publish the log message.

The call to mqtt_connect() can block for a while, so raise the log severity
of the "connecting to broker" message from DEBUG to INFO. Otherwise, a bad
MQTT broker address or port would make the servers just appear to hang during
initialization, for no reason.

Fixes issue #679

CryptCert.export_cert(CryptCert.FORMAT.TEXT_CERTIFICATE) should
now work properly instead of always returning an error.

Should fix issue reported on IRC by Dumas_Walker

DDMsgReader: New configurable colors for the indexed mode sub-board menu: indexMenuSeparatorLine and indexMenuSeparatorText

See merge request !374

Eric Oulashin authored 1 year ago and Rob Swindell committed 1 year ago

DDMsgReader: New configurable colors for the indexed mode sub-board menu: indexMenuSeparatorLine and indexMenuSeparatorText

That doesn't trigger a Coverity defect this time (CID 470457)

Actually tested myself this time, needed a lot more than first appearances.

Also includes a security/safety enhancement where the @-code expanded string
is *not* used as an sprintf format string. Supporting both format specifiers
and @-codes in a single text.dat string is tricky (always has been).

For Accession.

resulting from commit 5f1c39f0

Fix for issue #678

SlyVote: New menu-driven configurator. Minor code refactor; no difference in functionality.

See merge request !373

The first word of the message recipient or author's name.

For Accession.

Expected to use the MSG_* @-codes in this context. This allows more freedom
of ordering the message header fields reused in this expanded string. The %s
specifiers can be eliminated altogether when using @-codes.

For Accession to play with.

This just generated unnecessary noise in data/user/*.ini files, no harm.

iniSetObject (used by userprops.js) will set undefined properties as blank
keys in the section (oops, I don't recall if this is intentional or not), so
we need to 'delete' the property instead of assigning undefined to it.

With 0xE0 being used for ciolib "super-extended scancodes", a literal
0xe0 can't pass through the input path.  This is an issue in CP866 (р)
and KOI8-U (Ю) as well as CP437 α.

Should fix SyncTERM SF bug 123.

of sbbs_t::external()

The startup directory for DOS doors might not be a valid Unix (case-sensitive)
path, so let's just do that check in the native block here.

Also, removed a bunch of redundant startup_dir ==/!= NULL checks. It can't be
NULL here.

The '-l' (loop) option would cause the JS runtime to be destroyed and
recreated for each new execution of the script, which resulted in memory
leaks in Windows builds (see issue #672 for details). So instead, just
use a single JS runtime here when the -l option is used to prevent that
from happening, though truth be told, that's likely not a normal/common
occurrence. Other apparent JS-related memory leaks (e.g. in the web
server) appear to be of a common concern.

Likely upgrading to a modern libmozjs would also fix this issue, but
we're far short of being able to do that right now.

Other small typos/fixes.

More detail to debug a false-negative SyncBBS-detection result

This solves the problem of detecting a Synchronet (for OS/2) BBS at
telnet://wyseguybbs.mywire.org:2300

That system responds with some control characters (NULs and ^Cs)
before the initial welcome banner, so just strip those out.

This reverts commit cfcff881

... to de-clutter the log

Also, don't log the packet passwords. Folks copy and post sbbsecho.log lines
and that could seriously compromise the security of the Interwebs if those
super-secret passwords were ever leaked!