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.
Alexander Barton