This ensures server linking uses the latest available TLS version, not
just TLSv1.
Taken partly from
https://github.com/charybdis-ircd/charybdis/commit/73470f0b3c0b3dc8ecce6823a9d2d630ccca76bb
probably could do with a few more backports, but this makes things work
again.
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.
Tweak auto-accept:
* 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
William Pitcock [Sat, 3 Jul 2010 05:44:55 +0000 (00:44 -0500)]
Stop griefing through taunting while hiding behind CALLERID.
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.
Jilles Tjoelker [Sat, 8 May 2010 22:30:51 +0000 (00:30 +0200)]
openssl: Avoid cutting off OpenSSL errors at 119 chars.
ERR_error_string() is just broken, as it returns at most 119 chars
which means error messages are frequently truncated.
Allow for 511 chars using ERR_error_string_n().
Jilles Tjoelker [Sat, 8 May 2010 22:30:51 +0000 (00:30 +0200)]
openssl: Avoid cutting off OpenSSL errors at 119 chars.
ERR_error_string() is just broken, as it returns at most 119 chars
which means error messages are frequently truncated.
Allow for 511 chars using ERR_error_string_n().
Stephen Bennett [Fri, 30 Apr 2010 21:01:21 +0000 (22:01 +0100)]
Rework ircd-side MLOCK enforcement: instead of trying to track modes locked on or off, instead keep a simple list of mode letters that are locked, and reject any change to those modes.
Do not allow a topic change if a user may not send to the channel
(resv, cmode +m, cmode +b, cmode +q, etc.).
This is only checked for local users.
For optimal compatibility, a failure for this reason still
returns ERR_CHANOPRIVSNEEDED.
Side effect: normal users cannot change topics of resv'ed
channels, even if they have ops, just like they already
cannot send messages. This only matters if resv_forcepart
is disabled, as the user would have been removed from the
channel otherwise.
Jilles Tjoelker [Wed, 31 Mar 2010 23:16:16 +0000 (01:16 +0200)]
New custom channel mode API allowing reloading such modules.
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.
Jilles Tjoelker [Sun, 14 Mar 2010 16:21:20 +0000 (17:21 +0100)]
Add option general::use_propagated_bans to allow disabling new KLINE.
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.
William Pitcock [Mon, 8 Mar 2010 05:13:39 +0000 (23:13 -0600)]
Add propagation of MLOCK state for simple modes.
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.
Jilles Tjoelker [Fri, 5 Mar 2010 17:36:44 +0000 (18:36 +0100)]
Add propagated klines.
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.