After a configuration change (or deoper with no_oper_flood) sent_parsed
might be way higher than allow_read, so that the user would have to wait
a long time before the server responds. Avoid this.
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.
After setting up signal handlers, unmask the signals we care about
(installed handlers for).
When handling SIGINT, the kernel adds SIGHUP and SIGINT to the signal
mask (as requested in sigaction()); if execve() is called from the
signal handler, this change is persistent.
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.
yy_oper->certfp was not copied into yy_tmpoper->certfp, thus the information was lost and certfp auth was never really working, since the string was always empty.
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.
Do not allow a user to op themselves if they are
already opped, as "already opped" could be because
of OMODE's hack which will be unconditionally
reverted after the mode change.
Also, this matches old behaviour for users not
being able to generate mode changes redundantly
opping themselves.
Note that this change should only be taken advantage
of if all servers run patched code. Otherwise, mode
changes will be silently dropped and a desync
results.
The extended-join client capability extends the JOIN message with information clients typically
query using WHO including accountname, signon TS and realname.
These seem unnecessary and may cause problems because they
are wrong in some cases.
A comment says these were needed for GCC 3.3. If you are
still using this compiler, check this and if it breaks,
some other approach is needed.
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.
* 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.
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.
Any kline (or various other things) containing * or ? is
a mask kline and not an IP kline. Ideally, rb_inet_pton_sock()
would return failure for those, but in practice this is not
always the case for IPv6.
Such a kline that is erroneously treated as an IP line
likely matches way fewer IPs than expected.
This lets a user connect with a client certificate, and
passes the certificate's fingerprint to ircd, which
currently just notices it to the user.
A new ssld->ircd message 'F' is used to pass on the
fingerprint.
This is only for OpenSSL for now, not GNUTLS.
