Alexander Barton [Wed, 18 Jan 2017 23:06:46 +0000 (00:06 +0100)]
Fix handling of connection pool allocation and enlargement
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?
- Add more comments/documentation.
- Add dependencies for services and proxy scanners.
- Add more limit configurations.
- Allow AF_UNIX address family, required for syslog!
- Add homepage :-)
- Remote CAP_SETUID and CAP_SETGID from CapabilityBoundingSet: This is
nor needed, because the unit already sets User=irc and Group=irc.
- Add RestrictAddressFamilies, and restrict it to AF_INET and AF_INET6.
- Read in the Debian "default files", but note: only PARAMS is supported!
- Update debhelper compatibility to version 9.
- Update build-dependencies.
- Change group of ngircd.conf to "irc" in postinst script (this makes
starting ngIRCd as user "irc" easier, for example when using systemd).
- Don't create /var/run/ircd during installation: this is handled by the
SysV init script and the systemd service already.
Immediately shut down connection on receiving ERROR
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.
G-LINES: Forbid remote modifications if "AllowRemoteOper" is not set
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) ...
Christoph Biedl [Mon, 5 Dec 2016 19:26:00 +0000 (20:26 +0100)]
Fix building ngIRCd with OpenSSL 1.1
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).
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 ...
- Update x86_64/apple/darwin15.6.0 (Apple clang 8.0)
- Update x86_64/unknown/linux-gnu (gcc 4.9.2)
- Update i386/pc/solaris2.11 (gcc 4.8.2), tests have been run both on
Solaris 11.2 and Solaris 11.3 successfully, but the system identifier
is the same ... Thanks to Götz Hoffart <goetz@hoffart.de>!
Alexander Barton [Sat, 19 Dec 2015 18:23:50 +0000 (19:23 +0100)]
autogen.sh, ngindent, platformtest.sh: Fix warnings of "shellcheck"
- SC2006: Use $(..) instead of legacy `..`.
- SC2015: Note that A && B || C is not if-then-else. C may run
when A is true.
- SC2086: Double quote to prevent globbing and word splitting.
- SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
This setting allows to run multiple ngIRCd instances with separate 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.
Thanks to "somechris" for the patch & pull request!
Add PAMServiceName setting to specify the used PAM configuration
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`.
This combination had been successfully tested with ngIRCd 21, but after
further investigation didn't build correctly: it seems as if tcc fails
to correctly link external libraries (e. g. ngipaddr).
Astonishingly the test suite passed nevertheless, with garbled output,
but without the daemon crashing!?
When using tcc with ngIRCd 23 (and current master), the test suite fails
completely because the daemon crashes ... (which actually is good!)
Alexander Barton [Sun, 10 Jan 2016 16:39:43 +0000 (17:39 +0100)]
platformtest.sh: Only show "runs=Y" when test suite succeeded
Display "?" in the "runs" colum when the simple "run test" succeeded but
the test suite failed. And display a message to double check the actual
status, because it is somewhat unclear, if the daemon actually "works"
or not in this case.
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!
Limit the number of message targes, and suppress duplicates
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.
Get rid of unclever assert() in Send_Message_Mask()
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.
Alexander Barton [Sun, 13 Dec 2015 20:56:07 +0000 (21:56 +0100)]
Make NJOIN handler more fault-tolerant
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.
Alexander Barton [Sun, 13 Dec 2015 20:48:31 +0000 (21:48 +0100)]
IRC_KillClient(): Don't break when called without "Client"
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!
Christoph Biedl [Tue, 25 Aug 2015 16:12:05 +0000 (18:12 +0200)]
Reproducible builds
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.
Peter Powell [Tue, 14 Jul 2015 13:37:42 +0000 (14:37 +0100)]
Use "NOTICE *" before registration instead of "NOTICE AUTH".
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.
projects / ngircd / log