A zero CAP_CAP caused duplicate CAPAB to go undetected, allowing a
mismatch between what is sent out via ENCAP GCAP and what applies locally.
A zero CAP_TS6 allowed server connections without SID (with a valid
connect block).
Currently, the resolver treats SERVFAIL, NOTIMP, and REFUSED queries the
same as NXDOMAIN, but this really should not be the case. Instead, if
the DNS server errors on our request or provides an invalid request, try
another server.
Also, count DNS server errors in addition to timeouts and avoid these
undesirable servers.
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.
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.
Specifically, what this capability manager does, is map keywords to
calculated bitmasks. These bitmasks are allocated at runtime, so that
the any managed capability index can be manipulated by modules.
Modules should call capability_orphan() when orphaning capabilities. This
makes it so that bitmasks aren't reallocated, except for cases where the
capability is the same.
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.
* 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.
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.
The extended-join client capability extends the JOIN message with information clients typically
query using WHO including accountname, signon TS and realname.
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
Additionally, attempting to use too many modes or two times
the same letter is now detected and prevented.
Modules now request that a channel mode be added/orphaned,
instead of ugly manipulation from which that request had
to be guessed.
Slight changes are needed to modules that provide channel modes.
From the old API, one important function has been made static,
the other important function has been renamed, so loading old
modules should fail safely.
If this option is yes (default), KLINE by itself sets global (propagated) bans.
If this option is no, KLINE by itself sets a local kline following cluster{},
compatible with 3.2 and older versions.
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
Such bans are not applied locally, but are propagated normally.
They can only be removed on a server that applies them.
Note that normally KLINE will not accept such bans.
This is mainly for services, differing min_wildcard and
ircd changes.
A KLINE command without the ON clause now sets a propagated
("global") ban. KLINE commands with the ON clause work as
before.
Propagated klines can only be removed with an UNKLINE command
without the ON clause, and this removes them everywhere.
In fact, they remain in a deactivated state until the latest
expiry ever used for the mask has passed.
Propagated klines are part of the netburst using a new BAN
message and capab. If such a burst has an effect, both the
server name and the original oper are shown in the server
notice.
No checks whatsoever are done on bursted klines at this time.
The system should be extended to XLINE and RESV later.
There is currently no way to list propagated klines,
but TESTLINE works normally.
The value 0 indicates the creation time is unknown (currently the case
for bandb).
Also store a creation time for xlines and resvs, but do not use it yet.
When a user receives a private message, notice or RPL_UMODEGMSG,
add the source to a special set of 5 target slots.
These slots are checked in the normal way when sending messages,
allowing a reply without using up a free target.
This feature will not be very useful if a user is being messaged
by many different users; to help this, messages blocked entirely
by +g or +R do not affect the targets. CTCP replies also remain
free in terms of targets.
The server protocol for this is
:<uid> ENCAP * CERTFP :<40 hex chars>
both in new user introductions and in burst.
As in oftc-hybrid, only the user themselves and opers can see the certfp.
Displaying the certfp on connect seems unnecessary to me,
the user can whois themselves if needed.
A notice will be sent to any force parted users that the channel
is temporarily/permanently unavailable on the server.
A new config option channel::resv_forcepart can be used to disable this.
from ircd-ratbox (dubkat)
A large group is any $$ or $# or a channel with more than
floodcount/2 local members, checked on each server separately.
Note that floodcount checks are done on the sender's server.
The special treatment is active for 15 seconds.
Spaces in xline.conf files are changed to \s in memory
and recognized on unxline, but are not changed in the
file. New xlines are added to xline.conf files with \s.
xline.conf written by this commit or newer will not work
properly with charybdis older than 1124:131254925f32 (which
introduced \s support in match_esc()).
to restrict channel names to printable ascii only.
Like disable_fake_channels this only applies to joins
by local users; unlike disable_fake_channels it applies
to opers as well.
Note that in some cases (different TS delta settings,
heavy lag) it is possible only one of the servers
detects the problem and autoconnect may be left enabled.
The mechanism used for disabling is the same as
/quote set autoconn <server> 0; the A flag in /stats c
disappears and a rehash or /quote set autoconn can put
it back.
Use /quote help who for details.
The format code "o" (oplevel) is not documented,
but implemented showing dummy information (999 for
chanop, n/a otherwise).
Specifying need_ssl on auth{} denies the connection if
it is not SSL/TLS, much like need_ident or need_sasl.
Specifying need_ssl on operator{} refuses opering with
ERR_NOOPERHOST if the connection is not SSL/TLS.
from ircd-ratbox
Throttle replaces max_unknown_ip, reject is like before
(including the charybdis-specific unkline handling).
Both of these now apply before SSL negotiation.
This commit does not include the global_cidr and new dline code.
m_webirc is a bit nasty with throttling (unlike before
with max_unknown_ip), this may be fixed later (or
the webirc IP needs to be exempt{}ed).
