Conf_GetServer() can return NULL when the server introducing the client
had a write error for example, and is being disconnected.
So make sure that we have a valid server before calling Conf_NickIsService()!
This fixes the following compiler warning, for example on OpenBSD:
conf.c: In function 'Conf_Test':
conf.c:391: warning: format '%ld' expects type 'long int', but argument
2 has type 'time_t'
Thanks to Götz Hoffart for reporting this!
Basically, the issue described in #281 is that the test suite uses the
IPv4 address 127.0.0.1 on an IPv6-only host. But this is the "safest"
thing to do in (almost) all other setups: relaying on DNS host names
makes things even more complex, as different systems map 127.0.0.1
differently (including the reverse lookup; that's why we switched to
127.0.0.1 back in 2014, see commit 3f807e1045).
But with AI_ADDRCONFIG set, on an IPv6-only host, we prevent 127.0.0.1
to get translated properly, even when the loopback interface has this
address configured! So don't set it any more.
The drawback is that the resolver possibly returns more addresses now,
even of an unsupported/not connected address family; but this shouldn't
do much harm in practice, as ngIRCd iterates over all returned addresses
while trying to establish an outgoing connection.
Closes#281.
The ISUPPORT(005) numeric lists only channel prefixes which are listed
in the "AllowedChannelTypes" configuration option. And if this is the
empty string ("") for example, this now results in IRC clients assuming
"oh, no channel prefix characters at all, so no channels at all, so no
PRIVMSG can go to any channel" -- which is not the case when there are
pre-defined channel set up or other servers still having channels!
So "allowed channel types" != "supported channel types", and we always
have to list all supported ones in the ISUPPORT(005) numeric!
This reverts commit 4b7e8db418.
Closes#285.
On reload, all listening ports are closed, configuration updated, and
then opened again. Which leads to subsequent tests running while the
daemon isn't listening on any ports, and that's why the tests fail.
The "proper" way whould be to loop and check for open ports, but waiting
is what the start-server.sh script does right now, so stick with this in
reload-server.sh for now as well.
This fixes the issue, at least on my RaspberryPi ...
Closes#280.
It can happen that a channel is +k, but no key is set: for example by
misconfiguring a pre-defined channel. In this case, ngIRCd sent an
invalud CHANINFO command ("CHANINFO #test +Pk 0 :'", note the unset
key represented by the two spaces) to its peers.
Fix this and enhance the CHANINFO documentation.
The SERVER command is only valid with a prefix when received from other
servers, so make sure that there is one and disconnect the peer if not
(instead of crashing ...).
This obsoletes PR #275.
Thanks Hilko Bengen (hillu) for finding & reporting this as well for the
patch & pull request! But I think this is the "more correct" fix.
Prior to this commit, the PONG wasn't registered correctly, becauuse the
"last ping" time was set to time(NULL), which could be bigger than the
"last data" time stamp, for example when handling the read buffer took
more than 1 second -- and this resulted in the PONG time out kicking in
effectively disconnecting a newly linked server for example, because
ngIRCd thought it was still waiting for a PONG: last data < last ping.
Now the "last ping" value has three possible values:
0: new connection, no PING, no PONG so far.
1: got a PONG, no longer waiting for a PONG.
<t>: time stamp of last sent out PING command.
This patch completely broke the PING-PONG logic: now ngIRCd never
disconnects any stale peers but keeps sending out PINGs over and over
again ...
The real issue (server disconnects right after connect) will be fixed in
the next commit, but let's revert to the somewhat "half-broken but
'known' state" first ...
This reverts commit 79a917f954.
Change the line buffer in the Read_TextFile() function from 127 to
COMMAND_LEN (=512) bytes. Lines can't even get that long, because they
have to be prefixed before being sent to the client, so this is a sane
maximum.
This allows for even more "fancy" and "wider" MOTDs :-)
Closes#271.
Don't use the "standard" IRC SSL port 6697, as this easily collides with
real (ng)IRCd instances running on the same machine.
And by reusing port 6790, which is already used by the "test server #2",
we don't need any other port than the test suite already uses.
Not sure about the portability of strpbrk() in really ancient OS, and
this was the only place where it became used recently in ngIRCd ...
So let's play it safe! ;-)
There is no point in waiting up to one second for the network receiving
new data when there is still a read buffer holding at least one command;
we shouldn't waste time but handle it immediately!
If there are more bytes in the read buffer already than a single valid
IRC command can get long (513 bytes, COMMAND_LEN), wait for this/those
command(s) to be handled first and don't try to read even more data from
the network (which most probably would overflow the read buffer of this
connection soon).
This reverts commit c6e3c13f27.
This sounded like the right approach at first, but I'm not that sure
that it really makes sense to have different sizes of read buffers: the
per-connection read buffer only needs to keep data that is needed to
parse one full command, be it plain text, encrypted and/or compressed.
Then ngIRCd should handle this one command, move leftover data to the
beginning of the buffer and read the next chunk from the network that is
missing to get the next complete command (512 bytes at max).
So I revert this for now and try to fix the logic in Read_Request(),
which is broken nevertheless, as it results in servers becoming
disconnected during "server burst" when "big" lists are transferred.
The name of the Config_Error() function is misleading: it is not only
used to show configuraton errors, but all messages shown during normal
operation as well as for "config testing": it takes care of the correct
formatting of the messages (syslog, forground logging, config testing).
This fixes commit bb1d014aba.
This is required because the PING can be received quite a bit earlier
than it is actually handled, for example during "server burst" or other
heavy operations:
So the times won't match and PING-PONG logic would become garbled,
because we test for "last ping > last data" to determine if a PING
already was sent or not.
Remove legacy configuration options and related functions that have
been marked for removal for some time:
- PredefChannelsOnly (v22)
- NoticeAuth (v24)
- NoXXX (v19)
- Old '[GLOBAL]' section handling (v19)
This applies the same logic we have for write buffers to distinguish
between server and client connections and sets the maximum buffer size
accordingly. As a result peering with servers with many GLINE/KLINEs
does not kill the connecting server connection anymore.
Depending on the stack size, too many clients on the same channel
quitting at the same time would trigger a crash due to too many
recursive calls to Conn_Close().
This requires keeping track of currently active certificates, so those
are stored separately, along with a reference counter, and discarded
when they are no longer in use.
Fix the handling of legacy "Key" and "MaxUsers" [Channel] settings:
- Activate them before evaluating the "Modes" parameter, to allow the
latter to override those legacy options.
- Enforce setting the respective +k/+l mode(s) to support the legacy
"Mode = kl" notation, which was valid but is an invalid MODE string:
key and limit are missing! So set them manually when "k" or "l" are
detected in the first MODE parameter.
- Sort modes +kl alphabetically, adjust test suite accordingly.
Fix the following Clang "LeakSanitizer" error (which isn't quite
relevant in this test program, but anyway):
ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7f8c4d022810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x5601a801491a in Check_strtok_r (/net/arthur/home/alex/Develop/ngIRCd/ngIRCd.git/src/portab/portabtest+0x291a)
#2 0x5601a8014d77 in main (/net/arthur/home/alex/Develop/ngIRCd/ngIRCd.git/src/portab/portabtest+0x2d77)
#3 0x7f8c4c69009a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
FAIL: portabtest
Return with exit code 0 ("no error") when "--help" or "--version" was
used (this resulted in exit code 1, "error" before).
And exit with code 2 ("command line error") for all invalid command
line options, and show the error message on stderr (message was printed
to stdout before, and exit code was 1, "generic error").
This new behaviour is more in line with the GNU "coding standards",
see <https://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html>.
Previously, each server would cloak every user's hostmask. The problem
is that if a network has more than one server, then a user's hostmask
would get cloaked twice. This patch ensures that a server only cloaks
the hostmask if it has not yet been cloaked (the period indicates it's
still an IP address).
Closes#228.
This includes:
- "Real name" of a client (4th filed of the USER command).
- Server info text ("Info" configuration option).
- Admin info texts and email address ("AdminInfo1", "AdminInfo2" and
"AdminEmail" configuration options).
- Network name ("Network" configuration option).
The limit was 64 bytes before ...
Closes#258.
Don't exit during runtime (REHASH command, HUP signal), because the
server name can't be changed in this case anyway and the new invalid
name will be ignored.
- Show name of configuration file at the beginning of start up.
- Add a message when ngIRCd is ready, including its host name.
- Show name of configuration file on REHASH (SIGHUP), too.
- Change level of "done message" to NOTICE, like "starting" & "ready".
- Initialize IO functions before channels, connections, clients, ...
This option configures the maximum penalty time increase in seconds, per
penalty event. Set to -1 for no limit (the default), 0 to disable
penalties altogether. ngIRCd doesn't use penalty increases higher than 2
seconds during normal operation, so values higher than 1 rarely make
sense.
Disabling (or reducing) penalties can greatly speed up "make check" runs
for example, see below, but are mostly a debugging feature and normally
not meant to be used on production systems!
Some example timings running "make check" from my macOS workstation:
- MaxPenaltyTime not set: 4:41,79s
- "MaxPenaltyTime = 1": 3:14,71s
- "MaxPenaltyTime = 0": 25,46s
Closes#249.
For example:
* src/ngircd/irc-login.c:102:21: Implicit conversion loses integer
precision: 'int' to 'char'
* src/ngircd/conn.c:1084:9: Implicit conversion turns floating-point
number into integer: 'double' to 'bool'
* src/tool/tool.c:85:10: Implicit conversion loses integer precision:
'int' to 'char'
According to an IRCv3 extension, the 5th parameter can be used for extra
flags that are fine to ignore for now, but limiting WEBIRC params to 4
causes a syntax error.
See https://github.com/ircv3/ircv3-ideas/issues/12 for more information.
This closes#247.
When ngIRCd failed to spawn a new resolver subprocess, the connection
structure was still marked as "SERVER_WAIT", and no new attempt to
connect to this server was made.
Thanks to Robert Obermeier for reporting this bug!
Closes#243.
This patch fixes a "use after free" bug which is hit while processing
ERROR commands while a new client is logging into the server, which
leads to only the CLIENT structure becoming freed, but not the
CONNECTION structure, too. And this leads to the daemon accessing the
already freed CLIENT structure later on ...
So now IRC_ERROR() uses the correct function Conn_Close() to correctly
free both structures.
The CONNECTION structure is cleaned up later on, and the freed CLIENT
structure can't be overwritten during normal operations, therefore this
bug normally can't crash (DoS) the service -- but you can easily hit it
when using the GCC option "-fsanitize=address", or run ngIRCd with
Valgrind.
Thanks a lot to Joseph Bisch <joseph.bisch@gmail.com> for discovering
and reporting this issue!
This prevents the channel from becoming flooded by unecessary TOPIC
update messages, that can happen when IRC services try to enforce a
certain topic but which is already set (at least on the local server),
for example. Therefore still forward it to all servers, but don't inform
local clients (still update setter and timestamp information, though!)
Update user mode "C" handling ("Only users that share a channel are
allowed to send messages") to behave like user mode "b" ("block private
messages and notices") and therefore allow messages from servers, services,
and IRC Operators, too.
Change proposed by "wowaname" in #ngircd, thanks!
When compiling without "working getaddrinfo()", the "af" parameter of
ForwardLookup() is unused by that function. Mark it as such!
This prevents the following compiler warning:
resolve.c:235:56: warning: unused parameter ‘af’
[-Wunused-parameter]
When compiling ngIRCd without support for SSL and without support for
ZLIB, gcc outputs the following warning:
irc.c:493:9: warning: variable ‘options’ set but not used
[-Wunused-but-set-variable]
Fix it by providing a dummy function in this case.
This should fix the following compiler warning:
resolve.c:113:1: warning: ‘Get_Error’ defined but not used
[-Wunused-function]
Which can happen, because the logic of commit 543f44bf isn't sufficient:
Get_Error() is only used when neither HAVE_WORKING_GETADDRINFO nor
HAVE_GETNAMEINFO are set ...
Enhances 543f44bf.
Closes#241.
In the end, service clients behave like regular users, therefore IRC
operators and servers should be able to KILL them: for example to
resolve nick collisions.
This is related to #238.
The usage of Get_Error is guarded by "ifdef h_errno" in this file, the
definition of this function should follow the same rules.
Fixes a build error when cross-compiling:
https://github.com/ngircd/ngircd/issues/223
The daemon only enlarged its connection pool when accepting new client
connections, not when establishing new outgoing server links.
Thanks to Lukas Braun (k00mi) for reporting this!
In addition this patch streamlines the connection pool allocation, so
that there is only one place in the code allocating the pool: the now
updated Socket2Index() function. The name doesn't quite fit, but this
existing and today quite useless function (because the mapping from
socket number to connection index is 1:1 today) already became called
in almost all relevant code paths, so I decided to reuse it to keep the
patch small ...probably we want to fix the naming in a second patch?
Closes#231.
Don't wait for the peer to close the connection. This allows us to
forward the ERROR mesage in the network, instead of the very generic
"client closed connection" message.
Explicitely forbid remote servers to modify "x-lines" (G-LINES) when the
"AllowRemoteOper" configuration option isn't set, even when the command
seems to originate from the remote server itself: this prevents GLINE's
to become set during server handshake in this case (what wouldn't be
possible during regular runtime when a remote IRC Op sends the command)
and what can't be undone by IRC Ops later on (because of the missing
"AllowRemoteOper" option) ...
At the moment, ngIRCd fails to build against OpenSSL 1.1 since the
configure check probes for the SSL_library_init symbol which was
removed, but probing for a different function availabe in both versions
solves that problem: SSL_new().
And as SSL_library_init is no longer needed, the patch boils down to
probing SSL_new to assert libssl is available, and disabling the
SSL_library_init invokation from OpenSSL 1.1 on, see also another
application[1] (NSCA-ng) that did pretty much the same.
Patch was compile-tested on both Debian jessie (OpenSSL 1.0.2) and
stretch (OpenSSL 1.1).
[1] <https://www.nsca-ng.org/cgi-bin/repository/nsca-ng/commit/?id=8afc22031ff174f02caad4afc83fa5dff2c29f8a>
(Patch by Christoph, commit message cherry-picked from the email thread
on the mailing list by Alex. Thanks!)
This fixes the following correct -Wmisleading-indentation warning
messages of gcc 6.2:
irc-write.c: In function ‘IRC_SendWallops’:
irc-write.c:521:4: warning: this ‘if’ clause does not guard...
irc-write.c:524:5: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘if’
irc-write.c:526:4: warning: this ‘if’ clause does not guard... []
irc-write.c:529:5: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘if’
irc-info.c: In function ‘IRC_STATS’:
irc-info.c:895:3: warning: this ‘else’ clause does not guard...
irc-info.c:897:4: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘else’
No functional changes, the code has been correct, but the indentation
was wrong ...
This setting allows to run multiple ngIRCd instances with
PAM configurations on each instance.
If one sets it to "ngircd-foo", PAM will use `/etc/pam.d/ngircd-foo`
instead of the default `/etc/pam.d/ngircd`.
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)!
Don't crash the daemon when the NJOIN handler can't join the new client
to a channel (when the Channel_Join() function failed) but try to KILL this
client -- which is the only possible reaction besides crashing: otherwise
the network would get out of sync.
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.
ngIRCd tested for the wrong prefix of "half ops" when processing NJOIN
commands and therefore never classified a remote user as "half op".
Thanks to wowaname for pointing this out on #ngircd!
