On FreeBSD 4.8, fork(2) doesn't actually behave like fork(2).
Namely, kqueue(2) descriptors are not inherited by the child.
IOW, we can't fork(2) after we get the kqueue(2) descriptor.
So we'll just have to rely on people to actually read the
server log file if they want to understand why their server
is dying during startup.
This moves daemonisation to the end of initialisation which
vastly simplifies the reporting logic and eliminates the need
for the child to communicate to the parent.
This is a backport from the release/4 branch.
* Properly allow no DH parameters (some backends come with defaults)
* If no private key is given, assume it's in the certificate file
* Use correct length calculation in buffer for TLS options
* Fix compiler warnings regarding uint64_t stats counters
openssl:
* Don't manually initialise libssl 1.1.0 -- it does this automatically
* SSL_library_init() should be called first otherwise
* Move SSL_CTX construction to rb_setup_ssl_server()
* Test for all required files (certificate & key) before doing anything
* Free the old CTX before constructing a new one (Fixes#186)
* Properly abort rb_setup_ssl_server() on CTX construction failures
* Support ECDHE on more than one curve on OpenSSL 1.0.2 and above
* Clean up ifdef indentation
* Fix DH parameters memory leak
mbedtls:
* Fix certificate fingerprint generation
* Fix library linking order
* Fix incorrect printf()-esque argument count
* Return digest length for fingerprints instead of 1, consistent
with the other backends
sslproc / ssld:
* Fingerprint methods have no assocated file descriptors
* Send TLS information (cipher, fingerprint) before data
* Use correct header length for fingerprint method
Authored-by: Aaron Jones <aaronmdjones@gmail.com>
Authored-by: William Pitcock <nenolod@dereferenced.org>
Authored-by: Simon Arlott <sa.me.uk>
this avoids race conditions when a file descriptor is reused and an ssld worker has not acked that the previous
connection was closed, which results in the new client being kicked.
While functionally compatible with the implementation in ElementalIRCd, our approach is different,
specifically pre-calculating the bitmask at config load time. This is more efficient, and allows us
to report errors as part of the configuration phase.
