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!
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!
At the moment ngircd fails the tests for reproducible builds in Debian
since it uses the __DATE__ and __TIME__ macros for the INFO command.
Instead of patching this out I decided to implement an optional
constant BIRTHTIME that allows you to set a time stamp for the "Birth
Date" information, in seconds since the epoch, like in
export CFLAGS += -DBIRTHTIME=$(shell date +%s --date="2015/08/15 23:42:22")
In the future, Debian will provide a SOURCE_DATE_EPOCH environment
variable, dealing with the situation until then will be my job.
The time format was taken from the NGIRCd_StartStr formatting in
ngircd.c so the "Birth Date" and "On-line since" lines in the INFO
output look similar:
:irc.example.net 371 nick :ngIRCd 22.1-IDENT+IPv6+IRCPLUS+PAM+SSL+SYSLOG+ZLIB-x86_64/pc/linux-gnu
:irc.example.net 371 nick :Birth Date: Tue Aug 25 2015 at 18:11:11 (CEST)
:irc.example.net 371 nick :On-line since Tue Aug 25 2015 at 18:11:33 (CEST)
:irc.example.net 374 nick :End of INFO list
The format of the time stamped is changed, but as far as I can tell, there's no
rule that is violated by that.
Bonus level: Reformat the messages so the time stamps are aligned.
AUTH is a valid nickname so sending notices to it is probably not
a good idea. Use * as the target instead as done with numerics
when the nick is not available.
This mimics the behaviour in Charybdis, IRCD-Hybrid, InspIRCd 2.2,
Plexus 4, etc.
Reconnecting to ngIRCd 22.1 built with OpenSSL with some OpenSSL
clients, including Pidgin and stunnel 5.06, attempts to reuse a session
and fails due to the absence of this line.
The error message in syslog from ngIRCd is:
> SSL protocol error: SSL_accept (error:140D9115:SSL
> routines:SSL_GET_PREV_SESSION:session id context uninitialized)
This patch appears to fix the problem for both Pidgin and stunnel; it
may work for other OpenSSL clients that attempt to re-use sessions.
* <https://github.com/ngircd/ngircd/issues/182>
* <https://developer.pidgin.im/ticket/11568>
* <https://www.openssl.org/docs/ssl/SSL_CTX_set_session_id_context.html>
* LucentW/master:
Fix with oneshot invites
Fixed building issues\
Implement timestamp tracking of invites
Keep track of who placed bans/invites/excepts
IRC operators w/OperCanMode can kick anyone [already cherry-picked]
Closes#203, Closes#205.
For example, Interix is missing this function, which prevented
ngIRCd to build on this platform. When setgroups(3) isn't available,
a warning message is issued when ngIRCd starts up.
lightIRC and other clients expecting RPL_LISTSTART should now behave correctly.
Closes#207.
(cherry picked from commit 0680ce5fd99bc643651d1433bcdaf271aeb73c46)
Up to now, only the the string ("haystack") became lowercased and was
the compared to the pattern ("needle") -- which failed, when the pattern
itself wasn't all lowercase ...
- Update documentation in ngircd.conf(5)
- LIST: Don't hide channels for IRC Ops when "MorePrivacy" is in effect
- WHOIS: Don't hide IP addresses/hostnames when "MorePrivacy" is in effect
Closes#198
Now lists nodes also have the "onlyonce" field, since the valid_until is
used to keep the timestamp of placing. Found no references to onlyonce
or about valid_until being == 1, though, so it might be unused, but
still available for other enhancements.
Implement ERR_USERNOTONSERV(504) numeric and make sure that the
target user is on the same server when inviting other users to
local ("&") channels.
ircd-ratbox uses the ERR_USERNOTONSERV(504) numeric for this, and I
think this is a good idea -- other IRC daemons (like ircu) silently
drop such impossible invites, but thats not a big benefit ...
Idea by Cahata, thanks! Closes#183.
Up to now when receiving a MODE command, ngIRCd only reported the channel
creation time to clients that were members of the channel. This patch
reports the channel creation time to all clients, regardless if they are
joined to that channel or not.
At least ircd-seven behaves like this.
This closes#188. Thanks Cahata!
No other IRC daemon seems to do this (today?), don't remember why
ngIRCd did it in the first place ...
Closes#185.
Reported by Cahata in #ngircd, thanks!
The logic is reversed ...
This bug has been introduced by commit c74115f2, "Simplify mode checking on
channels and users within a channel", ngIRCd releases 21, 21.1, and 22 are
affected :-(
Problem reported by Cahata in #ngircd, Thanks!
Up to now, ban, invite, and G-Line lists have been synced between servers
while linking -- but obviously nobody noticed that except list have been
missing ever since. Until now.
Thanks to "j4jackj", who reported this issue in #ngircd.
David Binderman <dcb314@hotmail.com> reported the following compiler warning,
which is a real bug in ngIRCd, thanks!
conn.c:2077:55: warning: logical not is only applied to the left hand
side of comparison [-Wlogical-not-parentheses]
The "SYSLOG" #define isn't related to "Conf_ScrubCTCP" at all, so
initialize the latter even when "SYSLOG" isn't #define'd.
Pointed out by wowaname on #ngircd, thanks!
There are installations out there that would like to configure more
than 16 links per server, so increase this limit. Best would be to
get rid of MAX_SERVERS altogether and make if fully dynamic, but
start with this quick and dirty hack ...
Different operating systems do behave quite differently when doing DNS
lookups, for example "127.0.0.1" sometimes resolves to "localhost" and
sometimes to "localhost.localdomain" (for example OpenBSD). And other
systems resolve "localhost" to the real host name (for example Cygwin).
So not using DNS at all makes the test site much more portable.
Let IRC_MODE() detect that the "fake" MODE command originated on the local
sever, which enables all modes to be settable using "DefaultUserModes"
that can be set by regular MODE commands, including modes only settable by
IRC Operators.
