Links that are 'no-export' are not distributed to the rest of the IRC network (including local peers).
This provides a core primitive for 'anycasting' services (but the actual issue of synchronizing data in
a services package is left to the authors of the services package).
This is a forward-port of release/3.5 commit 566f4678
* Add generic direction enum for negotiation setup.
* Rename a rather long wrapper function to a shorter one consistent with
what it does.
* Rework context setup function.
* Don't check for handshake state before beginning handshaking.
The old backend began a handshake and then stepped into the callback
function if it was interrupted; the current one just jumps right into
it, so there is no need to check if it has previously succeeded,
because it hasn't been attempted yet.
* Add missing errno assignment to one of the handshake wrappers.
* Don't bother checking if SSL_P(F) is NULL when we already checked if
F->ssl is NULL -- this should be impossible.
* Don't bother checking if SSL_C(F) is NULL -- this was a no-op.
* Change the socket send and recv functions to not peer into a foreign
ratbox structure -- use the correct function to get the socket fd.
* Rewrap some lines and function arguments.
Other backends will be brought into line with this backend soon.
This will enable easier maintenance of the backends, by reducing the
diffs between them, which should make different behaviour easier to
spot.
At the moment, if a link quits in just the right (wrong [1]) way,
the quit reason will resemble:
<-- foo (~bar@baz) has quit (Read error: (-0x0) )
This should resolve that.
[1] Peers should send a close_notify alert before abruptly shutting
down their socket. This will result in a sane quit message:
<-- foo (~bar@baz) has quit (Read error: (-0x7880) SSL -
The peer notified us that the connection is going to be closed)
[ci skip]
This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
apply this fix if you support SASL on your servers, or unload m_sasl.so
in the meantime.
If initialising the server context fails, but the client one succeeds,
we will not only leak memory, but the error message reported for
initialising the server context might not make sense, because we
initialise the client context after and that could erase or change the
list of queued errors.
This scenario is considered rare. Nevertheless, we now initialise the
client context after *successfully* initialising the server context.
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.
Using /dev/random for salt generation is pointless -- it can block, and
any extra randomness it would provide (which is debatable) is not needed,
as salts only need to be unique, not unpredictable.
Commit cf12678 introduced a fix for issue #186 by freeing the old SSL_CTX
structure before constructing a new one, which could disconnect existing
clients otherwise.
Unfortunately, the freeing is done first, which means that if setting up
a new structure fails for any reason, there will be no usable structures
left, but they are still referenced.
This fix moves the freeing to the end of the function, using intermediate
new variables in the meantime. This problem was discovered while testing
against OpenSSL 1.1.0 RC6.
