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.
ngIRCd relaxes its flood protection for users having the user mode "F" set
and allows them to rapidly send data to the daemon. This mode is only
settable by IRC Operators and can cause problems in the network -- so be
careful and only set it on "trusted" clients!
User mode "F" is used by Bahamut for this purpose, for example, see
<http://docs.dal.net/docs/modes.html#4.9>.
ngIRCd uses "command throttling" and "bps throttling" (bytes per second).
The states are detected in different functions, Conn_Handler() and
Read_Request(), but handle the actual "throttling" in a common function:
this enables us to guarantee consistent behavior and to disable throttling
for special connections in only one place, eventually.
Change all #define's to follow the form
#define DEBUG_xxx {0|1}
to disable (0, default) or enable (1) additional debug messages.
And somewhat enhance some DEBUG_BUFFER messages.
This partially reverts commit b130b35f4, "Update #include's: remove
unused and add missing ones", but fixes the following compiler and
analyzer warnings of Apple Xcode 5:
"Semantic issue: No previous prototype for function 'yyy'"
The "deheader" tool (<http://www.catb.org/~esr/deheader/>) has been
used to find unused #include directives as well as missing ones.
Tested on:
- A/UX 3.1.1
- ArchLinux (2014-03-17)
- Debian GNU/Hurd
- Debian GNU/Linux 6.0.9
- Debian GNU/Linux 7.4
- Fedora 20
- FreeBSD 9.2
- OpenBSD 4.8
- OpenBSD 5.1
- OS X 10.9
- Solaris 11
Fix the following two errors emitted by the Apple K&R C compiler
on Apple A/UX:
"./class.c", line 47: no automatic aggregate initialization
"./class.c", line 47: illegal lhs of assignment operator
"./conf.c", line 1052: syntax error
Tested on A/UX 3.1.1.
The cloaked IRC mask of a user is his visible mask, so the daemon has
to use it for generating the "one time" entries for the invite list of
the given channel.
Without this patch, ngIRCd records the real IRC mask which will never
match while the target client is "+x", and even worse, will disclose
the real mask on "MODE #channel +I" commands :-/
Bug reported by Cahata on #ngircd, thanks!
This fixes commit 2e168c78 ("Return ISUPPORT(005) numerics on
'VERSION'") and make sure, that the 005 numerics are correctly
routed back to the sender.
Don't support "range marching" in our pattern matching code using
the "[...]" syntax, because [ and ] are valid characters in nick
names and one has to quote them currently using the "\" character,
which is quite unexpected. For example:
Nick "te[st" => "MODE #channel +b te\[st"
And remove quoting altogether, too, because "*" and "?" don't need
to be quoted because these characters are not allowed in IRC masks,
nicks, and hostnames.
Reported by "hifi" (Toni Spets) on IRC, thanks!
According to RFC 2812 3.2.3 "Channel mode message" and the examples
there, it looks like clients should use "MODE -k <key>" to unset channel
keys; and that's how other servers and services behave and do expect it.
(But please note that this is NOT the case for "MODE -l"!)
In the end, it doesn't make sense to specify a key when UNsetting it at
all, and different services behave diffrently when clients do not send
the currently set key to unset it - some ignore such calls, for example!
But this implementation is quite relaxed, it accepts any key when
unsetting channel mode "k" and even accepts no key at all. But the reply
will always include an "*" character for every "-k" parameter.
C99 states that vsnprintf() "returns the number of characters that
would have been printed if the n were unlimited"; but according to the
Linux manual page "glibc until 2.0.6 would return -1 when the output
was truncated" -- so we have to handle both cases ...
Test functions snprintf(), strlcpy(), strlcat(), vsnprintf() for
correctness, not only existance (which was quite useless, because
if they weren't available, the program could not have been linked
at all ...).
The new configuration variable "Network" is used to set the (completely
optional) "network name", to which this instance of the daemon belongs.
When set, this name is used in the ISUPPORT(005) numeric which is sent to
all clients connecting to the server after logging in.
Closes bug #165.
When DNS lookups are disabled, don't set the hostname received by the
WEBIRC command, but use the IP address instead.
Reported by Toni Spets <toni.spets@iki.fi>, thanks!
Closes bug #167.
At least AIX 4.3.3 and 5.1 have a broken implementation of getaddrinfo()
which doesn't handle "0" as numeric service correctly. This patch adds
a configure check for this case and changes all calling functions to only
use getaddrinfo() if it "works".
See <http://www.stacken.kth.se/lists/heimdal-discuss/2004-05/msg00059.html>
Increase the penalty for a command before checking its arguments. This
makes the handling more consistent and allow us to move more penalties to
Handle_Request().
This fixes the following error when compiling without zlib support:
irc.c: In function ‘Option_String’:
irc.c:487: error: ‘options’ undeclared (first use in this function)
Reported by "der_baer" on #ngircd.
FreeBSD prior to 10.0 does not automatically stir on fork(). Same with
current NetBSD. If arc4random_stir() is present assume is needed and
call it instead of srand().
This fixes the following warning on OpenBSD 5.3:
ngircd.o(.text+0xeb4): In function `main':
src/ngircd/ngircd.c:300: warning: strcat() is almost always misused,
please use strlcat()
Thanks to Götz Hoffart for reporting this!
Alexander Barton