Add the flags (auth{} spoof, dynamic spoof) to struct Whowas and add a
show_ip_whowas().
Normal users now see IPs of unspoofed users, and remote opers can see IPs
behind dynamic spoofs. Also, general::hide_spoof_ips is now applied when
the IP is shown, not when the client exits.
s_assert requires some higher-level functionality that shouldn't be
present in ircd_defs.h. ircd_defs.h is used by ssld, which has no notion
of logging or sending IRC messages. Additionally, some of the headers
s_assert depends on result in conflicting definitions in ssld.c.
This change also fixes the compile when using --enable-assert=soft.
This was broken by 6f7b36d5d0 in February
2013, as join failures are the only situation where a non-trivial
numeric is passed through from other code to be sent to a client. Fix it
by porting more code from ircd-ratbox 3.1.
With this comes an example module to block the killing of services.
NOTE: this will not cancel remote kills. Those are still accepted, per
the TS 6 specification.
Altering localClient->F without updating the FD hash leaves the struct
Client in the FD hash indefinitely which causes a crash later if the
struct is reused for a remote client. It also prevents error messages
from ssld showing up on IRC properly.
This will allow us to modularize message processing, e.g. having new modules to manipulate
channel and private messages in new ways.
Yes: it can be used to intercept messages, but such modules are already out in the wild for
charybdis anyway -- so this doesn't really change anything there.
If you are changing the text, then it is your responsibility to provide a pointer to a new
buffer. This buffer should be statically allocated and stored in your module's BSS segment.
We will not, and cannot, free your buffer in core, so dynamically allocated buffers will
cause a memory leak.
This will allow us to simplify m_message considerably, by moving channel mode logic out to
their own modules.
Arbitrarily prefer a forward channel to no forward channel and an
alphabetically higher forward channel to a lower one.
This is a simplistic implementation that generates one MODE message to
local clients for each ban removed (to be replaced).
For simplicity and to avoid amplification of incoming MODE messages,
regular modes may still desync the forward channel of a ban.
