Just don't check the python version at all.  If your python is older
than 2.5, you're already having other issues.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Just some more macOS silliness.

MinGW32 is getting long in the tooth and is missing a lot of modern
Windows features as well as having broken headers.  Most people will
be using MinGW-w64 at this point, so add support for it.  Once I
ensure SyncTERM works properly with it, MinGW32 support will be
discontinued.

I suspect this will impact exactly zero people since the reason this
exists is to build the Win32 versions of SyncTERM on FreeBSD.

Changes:
- Explicitly request 32-bit Windows output
- Detect the string "mingw32" anywhere in the hardware description
- Explicitly link with libuuid
- Add a terrible hack to syncterm.c to block wincrypt.h

This is used by some BBSs to enable encryption without needing to
integrate the BBS user base into their SSH server (and presumably
so they don't need to run multiple SSH servers).  All users log in
with the same username (ie: "bbs") and no password is requested or
required.

Once the BBS starts, it prompts for the BBS user name and password
as normal.

In SyncTERM, the user/password/syspass fields are redefined as
SSHuser/BBSuser/BBSpassword and they are moved around when you
change the connection type.  This means that if you change a listing
that has a syspass to SSH (no auth) and back, the syspass is lost.

I'm not sure if I plan to fix this or not.

It would be fine if this only warned while building JS, we're used
to ignoring that, but this bugger warns while building Synchronet
stuff.

Only supported on FreeBSD, Linux, Solaris, OS/2, GNU, Cygwin, and Darwin
Should allow OpenBSD to build JS engine.

Not yet tested, so more patches may be incoming.

Clang 11 throws an error if you do.

While PKCS#12 export likely works "fine", PKCS#12 import almost
certainly doesn't.  Cryptlib supports a basic strict PKCS#12 read,
while OpenSSL used wild and crazy extensions.

have contributed *something*." -- Cyan

backup the original.  Specify -b to make that happen.

Reported by apam.

Fixes errors connecting to newer OpenSSH systems.

So Deuce spent a lot of effort creating patches to the original Cryptlib v3.4.5
source files to tune cipher-suite selections/priorities to make modern SSH
clients (e.g. OpenSSH v7.6) and HTTPS/TLS browsers or security-checking
software happy. See the current list of 3rdp/build/cl-*.patch files for details.

32-bit Linux systems.

here, and it's not really needed.

The block sizes for TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 were incorrect in the suite
definitions.

This is the root cause befind the old cl-suites.patch which disabled
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (no great loss).  This patch also
fixes the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 suite, which may be what
new Apple phones were negotiating for pop3s connections.

and reported by wkitty42... you can turn ssh back on now. :D

despite them being manditory in the SSHv2 spec.

This fixes the error seen on old browsers using
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA after a DHE GCM fallure.

Thanks for all your help wkitty42!

Unbreak it.
While we're here, prefer ECDH so we get an 'A' from ssllabs.

they're enabled even if there is no usable oracle (ie: ssllabs.com).

This is easier than explaining to everyone who worries about it.  Hopefully
there's nothing left that requires TLS_RSA suites from the client.