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.
Add two mechanism for avoiding name-collisions in a system-wide
installation of charybdis. The ssld and bandb daemons, intended to be
directly used by ircd and not the user, install into libexec when
--enable-fhs-paths is set. For binaries which are meant to be in PATH
(bindir), such as ircd and viconf, there is now an option
--with-program-prefix=progprefix inspired by automake. If the user
specifies --with-program-prefix=charybdis, the ircd binary is named
charybdisircd when installed.
Add support for saving the pidfile to a rundir and storing the ban
database in localstatedir instead of in sysconfdir. This is, again,
conditional on --enable-fhs-paths.
Fix(?) genssl.sh to always write created SSL key/certificate/dh
parameters to the sysconfdir specified during ./configure. The
previous behavior was to assume that the user ran genssl.sh after
ensuring that his current working directory was either sysconfdir or a
sibling directory of sysconfdir.
This becomes important because of away-notify sending aways to common
channels much like nick changes (which are also paced).
Marking as unaway is not limited (but obviously only does something if the
user was away before). To allow users to fix typos in away messages, two
aways are allowed in sequence if away has not been used recently.
If a netburst adds bans or a channel TS change removes bans, +b/-b modes
are generated. Make sure these contain the forward channel, if any.
This appears also broken in ircd-seven.
This adds a new ISUPPORT token, NICKLEN_USABLE which is strictly an informative value.
NICKLEN is always the maximum runtime NICKLEN supported by the IRCd, as other servers may
have their own usable NICKLEN settings. As NICKLEN_USABLE is strictly informative, and
NICKLEN is always the maximum possible NICKLEN, any clients which depend on NICKLEN for
memory preallocation will be unaffected by runtime changes to NICKLEN_USABLE.
The default NICKLEN is 50; the default serverinfo::nicklen in the config file is set to
30, which is the NICKLEN presently used on StaticBox.
They are now in messages, even if client_flood_message_time is not 1.
If client_flood_message_time is not 1 (by default it is), this needs a
configuration change to maintain the same behaviour.
* Deduce allow_read from the client's state (IsFloodDone) rather than
storing it in LocalUser.
* Fix the documentation (in oper /info), however strange
client_flood_burst_rate and client_flood_burst_max may seem, that is
how they currently work.
nenolod gave the thumbs-up to port ircd-seven banfowards to charybdis to spb
for a while, and people have asked about it. Might as well do it since it's a
slow weekend.
Note that as a side effect use_forward is removed from the config and
unconditionally enabled!
While what chanroles are trying to accomplish is a good idea, it is
apparently unclear this is the proper way to do it. Until we figure out
the exact way we wish to do this, it should be reverted for now.
As jilles pointed out, it is best that the chanserv access list always
remain synced with the grant list. Thus, the ability for clients to set
this is not a good idea unless services knows about the grant, but this
leads to all sorts of messy issues and likely isn't worth it.
this makes setting new roles on a user much easier as we're just setting the roles they
should be having, instead of having to try to revoke roles we don't necessarily know
about.
The theory behind this is that services sends an ENCAP * GRANT #channel
UID :+flagspec message specifying the chanroles the user has. They are
mapped into flag bits and applied to the membership of the user. They
then are restricted or permitted to what they can do based on the
permissions mask regardless of rank.
For backwards compatibility, the default permission bit (without a GRANT
statement) allows a user to to anything an existing op can do ONLY if
they are an op.
Todo: make CHANROLE_STATUS work (the ability to apply +ov to people),
which is at the moment controlled by CHANROLE_MODE.
When we broadcast a KILL message, this generates server notices on all
other servers (assuming the target user exists). Therefore, we should
also send a notice to our local opers.
Do kick_on_split_riding if services sends an SJOIN
with a lower TS and a different key. This relies on
services restoring TS (changets option in atheme) and
services not immediately parting after receiving the
KICK, which is the case in recent atheme.
For invite-only channels, still only do
kick_on_split_riding in netbursts. Services is
assumed to handle this itself (atheme does).
Any hunted parameter with wildcards is now assumed
to be a server, never a user.
Reasons:
* fewer match() calls
* do not disclose existing nicknames
* more intuitive behaviour for CONNECT
m_trace has a copy of some hunt_server logic in it
(for the RPL_TRACELINK reply), so adjust that too.
The extended-join client capability extends the JOIN message with information clients typically
query using WHO including accountname, signon TS and realname.
The reason why we do this is because some clients are dependent on receiving a numeric
for every channel join failure, even due to this limit where it can be assumed that
subsequent joins failed.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
The code behind this capability was never implemented, and subsequent
discussions have agreed to approach the problem differently. There seems no
reason to continue advertising a capability that does nothing.
* does not apply to NOTICE (as those may well be automated)
* mirrors +g behaviour so that no useless accept entries are added for services
* respects max_accept, if it would be exceeded the message is dropped with numeric 494
* check moved up so this is checked before floodcount/tgchange
This shouldn't provide any way for a client to get on a CALLERID list
without authorization, as if a client is +g already, a CTCP request, for
example, won't be replied to.
