If your browser is from another geological epoch, I have no sympathy for you.

Previously, 403 was only returned if they existed, and 404 if they
didn't.

No need to get time() here since it's never checked.

Resolves CID 174292

Have free_paragraphs() explicitly allow paragraphs to be NULL and
have everything use the fail_return which now free()s ret.

Previously, more than 999 arguments would overrun a buffer and break
things.

Fixes CID 33313

Are you tired of getting TLS-related error log messages that you can't do anything about? e.g.
web  0139 TLS ERROR 'Received TLS alert message: Unexpected message' (-15) setting session active

The new sbbs.ini [web] TLSErrorLevel option (defaults to 0 / "Emergency") allows the sysop to set a cap (maximum severity) on TLS-related log messages in the web server (e.g. TLSErrorLevel=Warning).

x points to the terminating NUL in x64.  free()ing it would do wild
and crazy things depending on how paranoid the free() implementation
is.

free(x64) instead... at least Coverity was happy though!

The socket set allocated by xpms_create() was never freed. Found by Coverity.

Deuce said to just delete it. <shrug>

I'm not sure what echicken was trying here, but apparently it doesn't
work for nelgin.

Likely fixes #220.

I'm not sure what echicken was trying here, but apparently it doesn't
work for nelgin.

Likely fixes #220.

3rd party external doors - exitilus, jibben, jns

See merge request !110

3rd party external doors - exitilus, jibben, jns

See merge request !110

... instead of the JSON parse exception as reported via IRC:
<matjam> !finger ?bbs:Stupendous BBS@vert.synchro.net result: SyntaxError: JSON.parse

... instead of the JSON parse exception as reported via IRC:
<matjam> !finger ?bbs:Stupendous BBS@vert.synchro.net result: SyntaxError: JSON.parse

The Synchronet FTP server has (since 2001) disallowed PORT/EPRT/LPRT commands with a "reserved" port number (i.e. < 1024) as recommended by RFC2577 and when attempted, would log a "SUSPECTED FTP BOUNCE HACK ATTEMPT" in the data/hack.log file.

However, as Karloch (HISPAMSX) pointed out recently, an FTP Bounce Attack to other TCP ports was still possible (and detected/reported by some security scans as a potential vulnerability).

So, reject all PORT/EPRT/LPRT commands that specify an IP address other than that used for the control TCP connection unless the sysop specifically enables the new "ALLOW_BOUNCE" option flag (in the [ftp] section of sbbs.ini) and the user is an authenticated non-guest/anonymous user. And as before, log the attempt as a suspected hack attempt.

This change also removes the "Directory File Access" checkbox from the Synchronet Control Panel for Windows as that feature is "going away" soon (or at least, it won't be an FTP-specific option/feature if it remains).

The Synchronet FTP server has (since 2001) disallowed PORT/EPRT/LPRT commands with a "reserved" port number (i.e. < 1024) as recommended by RFC2577 and when attempted, would log a "SUSPECTED FTP BOUNCE HACK ATTEMPT" in the data/hack.log file.

However, as Karloch (HISPAMSX) pointed out recently, an FTP Bounce Attack to other TCP ports was still possible (and detected/reported by some security scans as a potential vulnerability).

So, reject all PORT/EPRT/LPRT commands that specify an IP address other than that used for the control TCP connection unless the sysop specifically enables the new "ALLOW_BOUNCE" option flag (in the [ftp] section of sbbs.ini) and the user is an authenticated non-guest/anonymous user. And as before, log the attempt as a suspected hack attempt.

This change also removes the "Directory File Access" checkbox from the Synchronet Control Panel for Windows as that feature is "going away" soon (or at least, it won't be an FTP-specific option/feature if it remains).

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.