The numeric RPL_WHOISHOST_MSG(378) returns the DNS hostname (if
available) and the IP address of a client in the WHOIS reply.
Only the user itself and local IRC operators get this numeric.
This allows to use "*!<user>@<host>" or "*!*@<host>" masks to reject
clients even before receiving PASS, NICK and USER commands and before
forking authentication child processes which reduces resource usage.
This allows a channel operator to define exception masks that allow users
to join the channel even when a "ban" would match and prevent them from
joining: the exception list (e) overrides the ban list (b).
If the target user of a PRIVMSG or NOTICE command has the user mode 'C'
set, it is required that both sender and receiver are on the same channel.
This prevents private flooding by completely unknown clients.
- Check correct list for duplicates when adding items.
- Don't generate any messages when adding duplicates or removing
non-existing items (this is how ircd-seven and ircu behave).
- Code cleanup: Add_Ban_Invite(), Del_Ban_Invite().
Commit 565523cb allowed processing of further channel names given to the
JOIN command when a single name was invalid.
After this patch, the JOIN command handler continues to process channel
name lists even after errors like "channel is full", "too many channels",
and the like and generates appropriate error messages for all the
channels given by the client.
Limit the MODE command to handle a maximum of MAX_CMODES_ARG (5) channel
modes that require an argument (+Ibkl) per call.
Please note: Further modes that require arguments are silently ignored
and end the handling of any further modes.
This is similar to the behavior of ircd2.11 (silently ignores but seems
to handle other modes) as well as ircd-seven (silently ignores but handles
some(!) other modes) ...
The assert(client != NULL) got triggered during our tests, so there is
an error path that resulted in the connection being still established
(sock >= 0) but the client structure already freed.
So Conn_Write() should handle it!
This reduces the possibility of flooding channels with commands like
"PRIVMSG/NOTICE #a,#n,#c,... :message" a little bit.
Problem noticed by Cahata -- thanks!
Until now, the penalty time has only been set when longer as the
already set one, so it didn't accumulate.
And add documentation for and clean up code in Conn_SetPenalty() and
Conn_ResetPenalty() functions.
This partly closes bug #118. ngIRCd still starts up even when
Server{UID|GID} is invalid: then the daemon falls back to "nobody"
when running with root(0) privileges (as before).
commit 15fec92ed7
(Update list item, if it already exists) can make ngircd
crash because 'Reason' can be NULL, as reported by
Cahata on the ngircd mailing list.
Doesn't affect any released ngircd versions.
Also, make sure that we do not pass NULL as arguments
to a '%s' printf-like function.
When JOIN is received with more than one channel name, don't stop
processing on the first error (e.g. bad name, wrong channel key, ...)
but report an error and continue with the other given channel names.
Reported by Cahata -- thanks!
When "PAMIsOptional" is set, clients not sending a password are still
allowed to connect: they won't become "identified" and keep the "~"
character prepended to their supplied user name.
This fixes two bugs:
- "WHO <nick>" returned nothing at all if the user was "+i"
(reported by Cahata, thanks).
- "WHO <nick|nickmask>" returned channel names instead of "*"
when the user was member of a (visible) channel.
Clean up code and add documentation as well.
Rename Channel_Count() to Channel_CountVisible() and only count channels
that are visible to the requesting client, so the existence of secret
channels is no longer revealed by using LUSERS.
Reported by Cahata -- thanks!
Unknown user and channel modes no longer stop the mode parser, but are
simply ignored. Therefore modes after the unknown one are now handled.
This is how ircd2.10/ircd2.11/ircd-seven behave, at least.
Reported by Cahata -- thanks!
This fixes:
irc-oper.c: In function ‘IRC_xLINE’:
irc-oper.c:429: warning: ‘class’ may be used uninitialized in this function
irc-oper.c:430: warning: ‘class_c’ may be used uninitialized in this function
If gai_strerror() isn't available, use a macro that simply returns
a static error message (regardless of the real error code).
For example, GNU libc 2.0.7 doesn't implement gai_strerror().
This fixes the problem that ngIRCd can't do any IDENT lookups because
of the socket has already been closed in the child process.
The bug has been introduced starting with ngIRCd 17 ... :-(
(commit ID 6ebb31ab35)
- User mode "R": indicates that the nick name of this user is "registered".
This mode isn't handled by ngIRCd itself, but must be set and unset by
IRC services like Anope.
- Channel mode "R": only registered users (having the user mode "R" set)
are allowed to join this channel.
DEBUG_BUFFER is off by default and therefore disables these messages:
- "Handle_Write() called for connection XX, YY bytes pending ..."
- "Connection XX: ZZ bytes left in read buffer."
* ServerMode:
Handle channel user modes 'a', 'h', and 'q' from remote servers
Handle unknown channel modes on server links
Handle unknown user modes on server links
IRC_MODE(), Client_Mode(): code cleanup [2/2]
Enlarge client user mode buffer, reduce client flags buffer
Infom clients when other servers change their user modes
IRC_MODE(), Client_Mode(): code cleanup [1/2]
These channel user modes aren't used for anything at the moment, but
ngIRCd knows that these three modes are "channel user modes" and not
"channel modes", that is that these modes take an "nick name" argument.
Like unknown user and channel modes, these modes are saved and forwarded,
but ignored otherwise.
We have to enlage our user mode buffer, so we can handle even unknown
user modes in the future; and reduce the client flags buffer, because
I can't imagine why we ever would need ~100 flags!?
Now we support up to 15 user modes (was: 8) and up to 15 flags (was: 99).
So in the end, we even save 99-15+8-15=77 bytes for each client structure!
Use ps(1) flag "-a" (as well as "-f"):
"Select all processes except both session leaders (see getsid(2)) and
processes not associated with a terminal."
Thanks to Götz Hoffart for reporting this problem!
On server-links, spoofed prefixes can happen because of the asynchronous
nature of the IRC protocol. So don't break server-links, only log a message
and ignore the command.
This fixes bug 113, see:
<https://arthur.barton.de/bugzilla/show_bug.cgi?id=113>
Citing an email from Florian to the ngIRCd mailing list:
"I wonder what the expected behaviour is when Conf_MorePrivacy is changed
from 'yes' to 'no' and the config is reloaded.
At the moment, WHOWAS will start giving out information on Users that
were connected during Conf_MorePrivacy=yes period. If this is not
wanted, Client_RegisterWhowas() should be changed to not store a record
when Conf_MorePrivacy is enabled."
And I think it is "not wanted" :-)
For outgoing connections, we use 2048 (DH_BITS) since commit 49b2d0e.
This patch enables ngIRCd to accept incoming connections from other servers
and clients that use at least 1024 bits (and no longer requires 2048 for
incoming connections, too).
Patch proposed by Florian Westphal.
this patch contains:
* Fix for Conf_CloakUserToNick to make it conceal user details
* Adds MorePrivacy-feature
MorePrivacy censors some user information from being reported by the
server. Signon time and idle time is censored. Part and quit messages
are made to look the same. WHOWAS requests are silently dropped. All
of this is useful if one wish to conceal users that access the ngircd
servers from TOR or I2P.
This patch makes it possible to scrub incomming CTCP commands from
other servers and clients alike. The ngircd oper can enable it from
the config file, by adding "ScrubCTCP = yes" under [OPTIONS]. It is
default off.
CTCP can be used to profile IRC users (get user clients name and
version, and also their IP addresses). This is not something we like
to happen when user pseudonymity/secrecy is important.
The server silently drops incomming CTCP requests from both other
servers and from users. The server that scrubs CTCP will not forward
the CTCP requests to other servers in the network either, which can
spell trouble if not every oper knows about the CTCP-scrubbing.
Scrubbing CTCP commands also means that it is not possible to send
files between users.
There is one exception to the CTCP scrubbing performed: ACTION ("/me
commands") requests are not scrubbed. ACTION is not dangerous to users
(unless they use OTR, which does not encrypt CTCP requests) and most
users would be confused if they were just dropped.
A CTCP request looks like this:
ctcp_char, COMMAND, arg0, arg1, arg2, .. argN, ctcp_char
ctcp_char is 0x01. (just like bold is 0x02 and color is 0x03.)
They are sent as part of a message and can be delivered to channels
and users alike.
The intention of this restructuring is to make the [Global] section much
cleaner, so that it only contains variables that most installations must
adjust to the local requirements.
All the optional variables are moved to [Limits], for configurable limits
and timers of ngIRCd, and [Options], for optional features.
The old variables in the [Global] section are deprecated now, but still
recognized.
The io_event_create error handling seems to miss a 'return'
statement.
Fix this by moving io_event_create() call around so we do not
need the Conn_Close/Init calls in the error case.
problem is that some clients refuse to connect to severs that only offer
1024. For interoperability it would be best to just use 4096, but that
takes minutes, even on current hardware.
parse.c:284: warning: suggest parentheses around operand of '!' or
change '&' to '&&' or '!' to '~'
The expression looks dubious, this should probably be
an if-not-set, then... test.
When the write buffer space grows too large, ngircd has to disconnect
the client to avoid wasting too much memory.
ngircd logs this with a scary 'write buffer overflow' message.
Change this to a more descriptive wording.
Not all servers (and services!) using the RFC1459 protocol style send
prefixes on all commands; so don't require them to do so.
This relaxes the requirements introduced by commit 15775e679.
We re-use the same helper function for both forward lookups
(when we want to connect to a peer server) and for validation of reverse
loopups (where we make a lookup on the hostname returned
by a reverse lookup on the IP address that connected).
Problem:
When ConnectIPv6=no, the forward lookup helper sets the adderss family
to AF_INET, and, if out client connected via ipv6, we fail to validate
the result.
Thus move the ConnectIPvX check out of the helper.
we do not need this for cryptographic purposes, but we can do better
than plain srandom(getpid()).
Also, keep in mind that rng state is inherited across fork(), so re-init
it in the child.
When enabled, this configuration option lets ngIRCd send a PING with an
numeric "token" to clients logging in; and it will not become registered
in the network until the client responds with the correct PONG.
This is used by QuakeNet for example (ircu/snircd), and looks like this:
NICK nick
:irc.example.net PING :1858979527
USER user . . :real name
PONG 1858979527
:irc.example.net 001 nick :Welcome to the Internet Relay Network ...
Make sure that all commands received from other servers do have
valid prefixes.
Only exceptions are PING and ERROR commands that can occure without
prefixes when generated by the remote peer itself.
