Alexander Barton [Fri, 19 Jan 2024 15:55:23 +0000 (16:55 +0100)]
Use -Werror when testing for -Wno-format-truncation
Clang does not know the -Wno-format-truncation option of (current) GCC,
but accepts unknown -W... options (exit core 0) but issues a warning
message on every invocation. So for example on macOS, where Clang is
used as "gcc", a new warning message was shown for every file to
compile, since we enabled -Wno-format-truncation in commit 1d527eaf:
Clang no longer acceps unknown -W... options by enabling -Werror, which
this patch adds to the CFLAGS while testing for -Wno-format-truncation,
which fixes this issue.
Alexander Barton [Thu, 18 Jan 2024 21:41:39 +0000 (22:41 +0100)]
Annotate "fall through" cases to silence warnings
Add a "/* fall through */" annotation to "case" statements which
actually should "fall through" to silences GCC warning like this:
hash.c: In function ‘jenkins_hash’:
hash.c:110:27: warning: this statement may fall through
[-Wimplicit-fallthrough=]
110 | case 12: c+=((UINT32)k[11])<<24;
| ~^~~~~~~~~~~~~~~~~~~~~
Alexander Barton [Thu, 18 Jan 2024 21:39:10 +0000 (22:39 +0100)]
Disable GCC -Wformat-truncation when suported
Pass -Wno-format-truncation when this is supported by GCC so silence
warnings like this:
conf.c: In function ‘Read_Config’:
conf.c:985:60: warning: ‘snprintf’ output may be truncated before
the last format character [-Wformat-truncation=]
985 | snprintf(file, sizeof(file), "%s/%s",
| ^
conf.c:985:25: note: ‘snprintf’ output 2 or more bytes (assuming 257)
into a destination of size 256
985 | snprintf(file, sizeof(file), "%s/%s",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
986 | Conf_IncludeDir, entry->d_name);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The warning is correct, but this is basically why we use snprintf() in
the first place.
Alexander Barton [Tue, 16 Jan 2024 16:33:54 +0000 (17:33 +0100)]
autogen.sh: Prefere automake 1.11 over other releases
GNU automake 1.11 is the last release supporting "de-ANSI-fication"
using the included ansi2knr tool. And becuase we _want_ to support old
K&R platforms, we try hard to use this release of automake when
available to generate our build system.
Alexander Barton [Mon, 15 Jan 2024 21:14:15 +0000 (22:14 +0100)]
Autodetect support for IPv6 by default
Until now, IPv6 support was disabled by default, which seems a bit
outdated in 2024. Note: You still can pass "--enable-ipv6" or
"--disable-ipv6" to the ./configure script to forcefully activate or
deactivate IPv6 support.
Alexander Barton [Mon, 15 Jan 2024 20:12:10 +0000 (21:12 +0100)]
Do IDENT requests even when DNS lookups are disabled
Without this patch, disabling DNS in the configuration disabled IDENT
lookups as well (for no good reason).
This patch allows enabling/disabling DNS lookups and IDENT requests
completely separately and enhances the messages sent to the client when
"NoticeBeforeRegistration" is enabled, too.
Channel Admins are not allowed to set Channel Owner status!
This was reported back in April 2021, thanks Sarah!
Subject: NGIRCD bug report
Date: April 28 2021, 14:30:08 MESZ
To: alex@barton.de
Hello,
I am writing to you to report a bug in ngircd.
In any give channel, if an user is with mode +a (admin), he/she can
sets mode +/-q(owner) to any other user. This is not inline with the
documentation.
I've looked into the code irc-mode.c, apparently an if block is
missing. Below are the code snippets that I believe fixes the bug.
Allow SSL client-only configurations without keys/certificates
You don't need to configure certificates/keys as long as you don't
configure SSL-enabled listening ports.
This can make sense when you want to only link your local daemon to an
uplink server using SSL and only have clients on your local host or in
you fully trusted network, where SSL is not required.
Respect "SSLConnect" option for incoming connections
Don't accept incoming plain-text ("non SSL") server connections for
servers configured with "SSLConnect" enabled.
If "SSLConnect" is not set for an incoming connection the server still
accepts both plain-text and encrypted connections.
This change prevents an authenticated client-server being able to force
the server-server to send its password on a plain-text connection when
SSL/TLS was intended.
Alexander Barton [Sun, 17 Sep 2023 17:38:53 +0000 (19:38 +0200)]
Various fixes and enhancements for the "Autojoin" patch
- Bring sample-ngircd.conf and ngircd.conf.5 description in line.
- Fix configuration parsing, it always showed the 'Unknown variable
"Autojoin"' error message, even when everything was perfectly fine.
- And fix a build error (at least on macOS with Apple Clang 14):
login.c:234:3: error: call to undeclared function 'IRC_JOIN'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
IRC_JOIN(Client, &Req);
^
The #include for the "irc.channel.h" header was missing!
- Remove a unused variable that caused a compiler warning:
login.c:222:12: warning: unused variable 'n' [-Wunused-variable]
size_t i, n, channel_count = array_length(&Conf_Channels, sizeof(*conf_chan));
^
- Add a explicit cast to fix a compiler warning:
login.c:235:15: warning: assigning to 'char *' from 'const char[51]'
discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
Req.argv[0] = conf_chan->name;
^ ~~~~~~~~~~~~~~~
Let's behave like most(?) other IRC daemons (at least ircd2.11) and hide
all +i users when WHOIS is used with a pattern. Otherwise privacy of
this users is not guaranteed and the +i mode a bit useless ...
Add "+DEBUG" to the version string only when configured with --enable-debug
The debug log messages are always available and a runtime option (since
commit c7de505c), but the assert()'s are only active when ngIRCd was
configured with the "--enable-debug" option.
So only add "+DEBUG" to the version string when the latter is the case.
michi [Sun, 1 Jan 2023 12:12:54 +0000 (13:12 +0100)]
Make the debug loglevel always available
This basically means to unifdef DEBUG in (almost) all places.
We keep it in src/portab/portab.h so DEBUG stays available to
enable assert(). Also add a comment about this.
Better validate MODE +k & +l parameters and return errors
Implement new numeric ERR_INVALIDMODEPARAM_MSG(696) and:
- Reject channel keys with spaces and return ERR_INVALIDMODEPARAM_MSG;
This was possible until now and resulted in garbled IRC commands later.
- Reject empty channel keys and return ERR_INVALIDMODEPARAM_MSG;
This was possible until now and resulted in garbled IRC commands later.
- Return ERR_INVALIDMODEPARAM_MSG when user limit is out of bounds;
This was silently ignored until now.
Channel modes +k & +l: Always report an error when a parameter is missing
This relates to #290 and considerations which errors to show when: and I
think it is the better approach to give feedback instead of silently
failing.
Note that this code path is also used when handling modes of channels
defined in "[Channel]" blocks in configuration files: in this case the
client is the local server and we can't send messages to it, because it
has no socket connection! Therefore we need those "is_machine" checks
and log an error im this case.
Alexander Barton [Mon, 26 Dec 2022 16:32:59 +0000 (17:32 +0100)]
Channel mode setting: The local server is allowed to work on local channels
Don't forbid the local server to change modes on local channels: this
happens when overriding modes on local (&) channels in the server
configuration file, for example, and is perfectly fine.
Without this patch, the server worked as expected but showed critical
error messages for each local channel in its configuration file:
"Got remote MODE command for local channel!? Ignored."
Alexander Barton [Tue, 29 Dec 2020 20:12:43 +0000 (21:12 +0100)]
Don't set AI_ADDRCONFIG, even when it exists
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 3f807e10457).
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.
Revert "Show allowed channel types in ISUPPORT(005) numeric only"
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!
Test suite: Wait 2 seconds after reloading the daemon
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 ...
Alexander Barton [Thu, 11 Jun 2020 14:45:30 +0000 (16:45 +0200)]
Don't send invalid CHANINFO commands when no key is set
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.
Alexander Barton [Mon, 25 May 2020 21:43:29 +0000 (23:43 +0200)]
IRC_SERVER: Make sure that the client sent a prefix
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.
Alexander Barton [Mon, 25 May 2020 17:02:16 +0000 (19:02 +0200)]
Fix PING-PONG handling when processing backlog in read buffers
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.
Alexander Barton [Sun, 24 May 2020 21:24:51 +0000 (23:24 +0200)]
Revert "Set the "last data" time to "last ping" time when updating the latter"
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 ...