But continue initializing/running for other non-TLS protocol support.

<Deuce> Feel free to not lock the mutex and never free/NULLify that string.
<Deuce> Should be nicer for people with separate logs, and a few bytes never hurt anyone.

handler it.

This is a new error that just started cropping up. I suspect it's related to recent SSH changes. This might help a little with context, when it happens again.

Totally not sketchy, trust me.

Interestingly, when they fail, Synchronet appears to crash.
This is fine.

These should've been static to begin with, like the other servers. Explains why FTP error message are with "term" as the server.

For Nightfox and his newsgroup reader thing: The strings that end up in the editor drop file (e.g. MSGINF) can now be passed as optional arguments to consol.editfile() and the underlying C++ API.

Allow maxlines (default:10000) to be overridden with an optional consol.editfile() argument too.

Previously, once a pubkey was attempted, you could not use a password.

328:25: warning: ‘pubkey’ may be used uninitialized

TLS 1.2.  For static services and JS sockets, add a new tls_minver
socket property which can be set to use a lower minver (down to the
wildly insecure TLS 1.0).

TLS 1.0 and 1.1 have been not reccomended since 2015, and deprecated
since 2021.

The client_socket_dup is overwritten after with the return value of accept(),
so this was likely a socket/handle leak (since commit 74470573, 17 years ago).

Noticed this only after logging a new error in an SSH connection when this
call to DuplicateHandle() failed for some reason (WinError 6), but it seems
like it's been redundant code for a long time now. So just ace it and possibly
fix a resource leak.

scfgnet.c:1463:25: warning: result of comparison of constant 100000 with expression of type 'uint16_t' (aka 'unsigned short') is always true

really no useful way to recover from failure.

This should fix the Clang warning that Deuce reported:
str.cpp:131:18: warning: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior

Still using BOOL where we need Win32 API compatibility.
Using JSBool instead of BOOL or bool where it matters.
Changed most relevant TRUE/FALSE to true/false too (though it's not as critical).

You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case.
Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case.

For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef).

I didn't convert UIFC yet.

This addresses issue #698

TLS clients don't (currently) add a certificate, so there's no need
to delete it.

Use cryptDestroySession() instead.

With this, it's not strictly necessary to clear cert_list in ssl_sync()
when the certificate changes, but it's still a good idea to prevent
unusable memory from being held onto.

warning: value computed is not used

Now each lock has an easily understandable purpose, and covers the
lowest possible amount of code.

It looks like Windows actually uses the name for matching existing
events, so if two events have the same name, they end up being the
same object.

On Win32, the name param is an LPCSTR which apparently is Microsoft
talk for const char *.

In C we're allowed to do whatever we want, but in C++, this matters
more.

Just running git commit --amend doesn't do -a it seems. :)

This should fix a long-standing issue where someone could connect to
the SSH port and do nothing, which would prevent other incoming
terminal sessions from being accepted until it times out.

Unfortunately, this means that Synchronet can't send any data until
authentication is completed, which means useful messages about why
you're being disconnected (ie: "Sorry, all terminal nodes are in use or otherwise unavailable.")
as well as usless information nobody ever cares about (ie: The IP
you're connecting from, that it is resolving your hostname, etc).
can no longer be sent to the user.

Reported by Max (WESTLINE)...

Introduced in commit 75c5c9e5, since we are now calling the set_state()
callback periodically, and in sbbsctrl, it sets/resets the pause button
checked (depressed) state in response to this callback (should it?), this was
resetting the pause button checked/depressed state peridically (at the
configured sem file check interval, default 2 seconds).

The fix: if the new server state is the same as the previously set server
state, don't call the set_state() callback. I considered this as a potential
optimization when I first wrote that commit, but didn't see any obvious
downside to calling the set_state() callback redundantly. Now that I see a
downside, let's implement this saving/checking of the state to avoid
redundant "set" calls.

... with a socket descriptor value of -1.