Clients can specify multiple targets for the "PRIVMSG", "NOTICE", and
"SQUERY" commands, separated by commas (e. g. "PRIVMSG a,#b,c :text").
Since commit 49ab79d0 ("Limit the number of message targes, and suppress
duplicates"), ngIRCd crashed when the client sent the separator character
only as target(s), e. g. "," or ",,,," etc.!
This patch fixes the bug and adds a test case for this issue.
Thanks to Florian Westphal <fw@strlen.de> for spotting the issue!
This prevents an user from flooding the server using commands like this:
PRIVMSG nick1,nick1,nick1,...
Duplicate targets are suppressed silently (channels and clients).
In addition, the maximum number of targets per PRIVMSG/NOTICE/... command
are limited to MAX_HNDL_TARGETS (25). If there are more, the daemon sends
the new 407 (ERR_TOOMANYTARGETS_MSG) numeric, containing the first target
that hasn't been handled any more.
Closes#187.
Either we use assert() to _guarantee_ a certain condition, or we use
if(...) to test for it. But never both.
So get rid of the assert() in Send_Message_Mask() and handle the case
that the target mask doesn't contain a dot (".") as regular error,
don't require the caller to assure that any more.
This polishes commit 5a312824.
Please note:
The test in Send_Message() is still _required_ to detect whether the
target is a channel (no dot) or a "target mask" (at least one dot)!
The IRC_KillClient() function is documented to handle the case that the
"Client" structure is NULL, so make sure that this actually works and
can't crash the daemon.
Please note:
The current code doesn't make use of this feature, so this fix is
definitely the "right" thing to do but doesn't fix an actual problem.
Now ngIRCd catches more errors on the server-to-server (S2S) protocol
that could crash the daemon before. This hasn't been a real problem
because the IRC S2S protocol is "trusted" by design, but the behavior
is much better now.
Thanks to wowaname on #ngircd for pointing this out!
The "deheader" tool (<http://www.catb.org/~esr/deheader/>) has been
used to find unused #include directives as well as missing ones.
Tested on:
- A/UX 3.1.1
- ArchLinux (2014-03-17)
- Debian GNU/Hurd
- Debian GNU/Linux 6.0.9
- Debian GNU/Linux 7.4
- Fedora 20
- FreeBSD 9.2
- OpenBSD 4.8
- OpenBSD 5.1
- OS X 10.9
- Solaris 11
This fixes the following error when compiling without zlib support:
irc.c: In function ‘Option_String’:
irc.c:487: error: ‘options’ undeclared (first use in this function)
Reported by "der_baer" on #ngircd.
The old local function Kill_Nick() in irc.c has been an ugly hack. This
patch implements a generic function for killing clients.
Adjust all callers of Kill_Nick() and respect the return code!
All places where Client_OperByMe() is used can either be converted to
Client_HasMode(Client, 'o') or Op_Check().
And Op_Check() itself can use the connection handle for deciding whether
the IRC Operator is a local user or not.
This function is used to send "error messages", including numerics,
back to clients and to automatically enforce a 2 second penalty. With
this patch, all error results enforces a delay for the client.
All callers of IRC_WriteStrClient(ERR_xxx) have been converted.
Please note that this patch prolongs the time "make check" needs
to complete its tests, because of lots of new enforced penalties ...
Make sure that all log messages end with a correct punctuation mark.
The rules for formatting log messages are:
1. Add punctuation marks to all messages passed to the actual logging
functions like Log() and LogDebug().
2. Don't add any punctuation marks to messages that are stored in
variables for later use or are passed over the network.
3. IP addresses, DNS host names and IRC server names should be quoted.
4. Messages originating in the network should be quoted (at least if
they are "untrusted" or variable).
Most probably this patch doesn't fix all mistakes, but it should be a
good starting point ...
* bug145-ProvideHelp:
Use "${docdir}/Commands.txt" as help text file
Add a note that "help file" is updated on startup and REHASH only
Add doc/Commands.txt which should document all commands
Implement Help() function parsing and returning the help text
Document "HelpFile" in sample-ngircd.conf and ngircd.conf.5
Implement new configuration option "HelpFile"
IRC_HELP(): Code cleanup
Refactor Read_Motd() into Read_TextFile()
This function parses the already read in help text and sends the requested
portions to the user. Parsing is done as following when a user user
issues a "HELP <cmd>" command:
1. Search the file for a line "- <cmd>",
2. Output all subsequent lines that start with a TAB (ASCII 9) character
to the client using NOTICE commands, treat lines containing a single "."
after the TAB as empty lines.
3. Break at the first line not starting with a TAB character.
This format allows to have information to each command stored in this file
which will not be sent to an IRC user requesting help which enables us to
have additional annotations stored here which further describe the origin,
implementation details, or limits of the specific command.
A special "Intro" block is returned to the user when the HELP command is
used without a command name.
Replaced error message for channel mode +M with ERR_NEEDREGGEDNICK_MSG
(used by Bahamut, inspircd, ircu & Unreal too) and using numeric 477
and the msg simliar like inspircd.
Replaced the error message ERR_CANNOTSENDTONICK_MSG for user mode +b
with ERR_NONONREG_MSG and using numeric 486, similar like unrealircd.
(cherry picked from commit 55a61ab17f63a9e757b7c7598c31b98ce5a132e8
and commit 3737d9ab7da1ea0485cefc07c65dc5308bf0db02)
When a user has set mode "b", all private messages and notices to this
user are blocked if they don't originate from a registered user, an IRC Op,
server or service. The originator gets an error numeric sent back in this
case, ERR_CANNOTSENDTONICK_MSG(976), which is/was(?) used by KineIRCd, too.
This closes bug #144.
If the target user of a PRIVMSG or NOTICE command has the user mode 'C'
set, it is required that both sender and receiver are on the same channel.
This prevents private flooding by completely unknown clients.
This reduces the possibility of flooding channels with commands like
"PRIVMSG/NOTICE #a,#n,#c,... :message" a little bit.
Problem noticed by Cahata -- thanks!
It is not possible to call Conn_Close() after Client_Destroy() has been
called, because Conn_Close wants to access the CLIENT structure which
then has been freed already.
Fix IRC_KILL to use Conn_Close() for local clients and Client_Destroy()
for remote clients only (and never both).