-int hooktype_mode_deop(aClient *sptr, aClient *victim, aChannel *chptr, u_int what, char modechar, long my_access, char **badmode);
+int hooktype_mode_deop(aClient *sptr, aClient *victim, aChannel *chptr, u_int what, int modechar, long my_access, char **badmode);
.. this to get rid of a compiler warning and potential problem.
Can't safely use shorts with variable argument functions I think,
or maybe only with reduced type checking which is not what we want.
-void hooktype_channel_synced(aChannel *chptr, unsigned short merge, unsigned short removetheirs, unsigned short nomode);
+void hooktype_channel_synced(aChannel *chptr, int merge, int removetheirs, int nomode);
m_pass and m_topic.c when duplicating strings with a length limit.
+/* strldup(str,max) copies a string and ensures the new buffer
+ * is at most 'max' size, including nul byte. The syntax is pretty
+ * much identical to strlcpy() except that the buffer is newly
+ * allocated.
+ * If you wonder why not use strndup() instead?
+ * I feel that mixing code with strlcpy() and strndup() would be
+ * rather confusing since strlcpy() assumes buffer size including
+ * the nul byte and strndup() assumes without the nul byte and
+ * will write one character extra. Hence this strldup(). -- Syzop
+ */
The output of /IRCOPS isn't meant to be client parsable anyway (which
can be seen by the use of bold text and such), so using a generic
numeric rather than wasting two others seems sensible.
Reported by The_Myth in #5066.
We only parsed the first A record reply, so if the blacklist returned
multiple results /and/ you would not have all those types in your
blacklist { } block then you could miss a hit (false negative).
This posed a limitation with utf8 PROTOCTL NICKCHARS=... and
potentially PROTOCTL SERVERS=... if having more than 32 servers.
The limitation has now been removed (buffer length = 512)
This is the "non breaking space" outside UTF8 and thus was previously
blacklisted. Keeping it blacklisted even if it appears in UTF8 is not
really an option as it means some UTF8 characters can never be used,
like the letter "nun" in Hebrew, and likely others.
module but at least the code can be updated on the fly (or replaced
with some other secondary alternative module in the future).
src/charsys.c -> src/modules/charsys.c
This also means everyone needs to load the modules/charsys module.
Naturally this is only available if the extbans/timedban module is
loaded and you should do so on all your servers on the same network
if you want to avoid confusion/desynchs.
These are bans that are automatically removed by the server.
The duration is in minutes and the mask can be any ban mask.
=> Note that you need to load the extbans/timedban module!
Some examples:
* A 5 minute ban on a host:
+b ~t:5:*!*@host
* A 5 minute quiet ban on a host (unable to speak):
+b ~t:5:~q:*!*@host
* An invite exception for 1440m/24hrs
+I ~t:1440:*!*@host
* A temporary exempt ban for a services account
+e ~t:1440:~a:Account
* Allows someone to speak through +m for the next 24hrs:
+e ~t:1440:~m:moderated:*!*@host
* And any other crazy ideas you can come up with...
Fix case where conv_param() returns NULL (ban rejected)
causing is_ok() function not to be called so the user
never sees the error. We now try to call the is_ok after
conv_param returns NULL.
So not really an API change, more like a fix.
the WEBIRC gateway gives us some assurance that the
client<->webirc gateway connection is also secure (eg: https).
This is the regular WEBIRC format:
WEBIRC password gateway hostname ip
This indicates a secure client connection (NEW):
WEBIRC password gateway hostname ip :secure
Naturally, WEBIRC gateways MUST NOT send the "secure" option if
the client is using http or some other insecure protocol.
https://github.com/ircv3/ircv3-ideas/issues/12
In 3.2.x we didn't fix these bugs since servers are trusted and
should send correct commands. In 4.0.x we changed this so we would
fix them when we come across such issues at normal priority (not
consider them security issues). I now took it a step further and
actively checked/looked for these issues and a bunch of them were
found. Almost all are NULL pointer dereferences, with some exceptions.
* S2S: MODE: check conv_param return value (NULL ptr crash)
* S2S: MODE: floodprot: More checks (NULL ptr crash)
* S2S: MODE: OOB write of NULL (write NULL past last element in an array)
* S2S: NICK: old compat fixes (NULL ptr crash)
* S2S: PROTOCTL: Check for double SID=
* S2S: SERVER: require at least 3 parameters (NULL ptr crash)
* S2S: SJOIN: require at least 3 parameters (NULL ptr crash)
* S2S: SJOIN: Fix OOB read (read 1 byte past buffer)
* S2S: TKL: validate set_at and expire_at (NULL ptr crash)
* S2S: TKL: require at least 9 parameters for spamf, not 8 (NULL ptr crash)
* S2S: TKL: ignore invalid spamfilter matching type (remove abort() call)
* S2S: TOPIC: querying for topic is not permitted (NULL ptr crash)
* S2S: UID: require 12 parameters (NULL ptr crash)
* S2S: WATCH: this is not a server command (NULL ptr crash)
* Fix OOB read (1 byte beyond string) for timevals. This was reachable
from config code, TKL (S2S) and /*LINE (Oper). In practice no crash.
* MODE: make code less confusing (effectively no change)
* TRACE: remove strange output in case of 0 lines of output
* Fix unimportant memory leak on boot (#4713, reported by dg)
* Fix small memory leak upon 'DNS i' (oper only command)
* Always work on a copy in clean_ban_mask(). This fixes a bug that could
result in a strlcpy(buf, buf, sizeof(buf)). So, overlapping strings,
which is undefined behavior.
* API change for HOOKTYPE_PRE_INVITE:
(aClient *sptr, aClient *target, aChannel *chptr, int *override)
Modules must now send the error message instead of only returning
HOOK_DENY. Also check for operoverride and set *override=1.
This so modules can send their own error messages instead of the
default message being sent ("channel is +V" - which is not true).
Reported by Gottem (#5023).
set::handshake-delay of 2 seconds by default. This will allow (most)
DNSBL checking to be finished before the user comes online, while
still allowing a smooth user experience.
If your DNS(BL) is slow then you could raise this setting slightly.
Bram Matthys