The max length is actually 126 (< 127), since the check errors out if
length >= 127. See
<https://github.com/ngircd/ngircd/blob/master/src/ngircd/conf.c#L1487>.
I didn't look through the history to see when the change happened. I
just happened to find during a migration that my 140 character MOTD
didn't work.
Update sample configuration file as well as the man page.
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.
