Without this patch, ngIRCd ignores SSL-related messages and continues
to start up but only listens on plain text communication ports -- and
this most probably isn't what the administrator wanted ...
Closes bug #163.
This patch introduces the possibility to arbitrarily select ciphers which
should be promoted resp. declined when establishing a SSL connection
with a client by implementing the new configuration option "CipherList".
By default, OpenSSL would accept low and medium strength and RC-4 ciphers,
which nowadays are known to be broken.
This patch only implements the feature for OpenSSL. A GnuTLS counterpart
has to be implemented in another patch ...
Original patch by Bastian <bastian-ngircd@t6l.de>.
Closes bug #162.
As per RFC whois should return 431 if no nick is provided. While
here convert upper check to use irc-macros. As a bonus we get to set
the penalty for free.
The configuration option "AllowedChannelTypes" must only be enforced for
regular clients and not for remote servers. Channels created by other
servres are always allowed, because they already exist and the daemon
must stay in sync with the network.
Without this patch, ngIRCd logged the "IDENT lookup for connection X:
no result"-message even when IDENT lookups have been disabled using the
"Ident = no" configuration option, which is a little bit misleading.
Reported by "btwe" in #ngircd.
This patch introduces a new field in the CLIENT structure, "ipa_text",
which points to an optional textual representation of the client IP
address (or NULL) which can be used to store the "real" IP address
information of a client using the "WEBIRC" protocol.
Without this patch, ngIRCd ignored the <ip-address> paramater ...
In addition, the functions Client_SetIPAText() and Client_IPAText()
have been introduced to set and get the textual representation of the
client IP address.
Client_IPAText() can be used even when no "IP address text" has been
set before, it then returns the real IP address of the connection.
Closes bug #159.
The new configuration option "DefaultUserModes" lists user modes that
become automatically set on new local clients right after login.
Please note that only modes can be set that the client could set on
itself, you can't set "a" (away) or "o" (IRC Op), for example! User
modes "i" (invisible) or "x" (cloaked) etc. are "interesting", though.
Default: set no modes (like without this patch).
Closes bug #160.
There have been code paths that ignored the return code of Handle_Write()
when sending "notice auth" messages to new clients connecting to the
server. But because Handle_Write() would have closed the client connection
again if an error occurred, this would have resulted in new errors and
assert()'s later on that could have crashed the server (denial of service).
Only setups having the configuration option "NoticeAuth" enabled are
affected, which is not the default.
CVE-2013-5580.
Channel_Modes() and Channel_Topic() return static memory that is zeroed at
creation time. Fix checking for empty modes and topic so they're propagated
correctly.
This function is used to send "error messages", including numerics,
back to clients and to automatically enforce a 2 second penalty. With
this patch, all error results enforces a delay for the client.
All callers of IRC_WriteStrClient(ERR_xxx) have been converted.
Please note that this patch prolongs the time "make check" needs
to complete its tests, because of lots of new enforced penalties ...
These functions usually write to more than one target, and therefore
can't return value indicating success or failure in a sane way. And, even
more omportant, these functions should send to as much as possible clients
and not stop at the first client which isn't reachable any more!
The new configuration variable "AllowedChannelTypes" lists all allowed
channel types (channel prefixes) for newly created channels on the local
server. By default, all supported channel types are allowed.
If set to the empty string, local clients can't create new channels at
all, which equals the old "PredefChannelsOnly = yes" setting.
This patch deprecates the "PredefChannelsOnly" variable, too, but it is
still supported and translated to the apropriate "AllowedChannelTypes"
setting. When "PredefChannelsOnly" is processed, a warning message is
logged.
Closes bug #152.
Move Announce_User() to client.c and rename it to Client_Announce().
Use this in cb_introduceClient() instead of duplicating the code.
This fix the certificate fingerprint announcement for new clients.
Also ensure the certificate fingerprint is only announced if the
client supports it (`M' flag).
This patch changes the handlers of the "PASS", "NICK", "USER",
and "SERVICE" commands to enforce a 2 second penalty when an error
like "need more/other parameters" occurs.
More functions should follow, I think ...
Now "IncludeDir" defaults to "$SYSCONFDIR/ngircd.conf.d" instead
of no directory, but a missing directory is only reported as an
error if it has explicitely configured in the main configuration
file and simply ignored otherwise.
Therefore it is now possible not to touch the default (sample)
configuration file at all, and set all distribution and/or system
specific configuration options in "*.conf" files stored in
"$SYSCONFDIF/ngircd.conf.d/".
Thanks to "Elmasloco" for the idea!
The option "IncludeDir" in the [Options] section can be used
to specify a directory which can contain further configuration
files and configuration file snippets matching the pattern
"*.conf" that should be read in after the main configuration
file ("ngircd.conf" by default) has been parsed.
Closes bug #157.
This function reads in and parses a single configuration file.
Adjust all other functions to display the correct name of the
file being read in currently.
As pointed by Alex while strl{cat,cpy} take the full length
we need to leave space to ensure a proper mask is always created
so revert the removal of - N from my last change.
Change callers accordingly so they don't rely on a global buffer and
rename Mask to Pattern where it makes sense since some functions
where indeed receiving a pattern and not a mask.
Change Lists_CheckReason() to receive a buffer where the reason
will be stored and its length. Change callers accordingly.
Change Class_GetMemberReason() (and its callers) in a similar way
so it doesn't rely on a global buffer for the rejected reason.
Fix the cb_clientserver_ssl() callback function to not read in and store SSL
encrypted client data before the asynchronous DNS resolver sub-process has
finished: This could have resulted in discarding the resolved client hostname
and IDENT reply afterwards, because in some situations (timing dependent) the
NICK and USER commands could have already been read in from the client,
stored in the buffer, and been processed.
Thanks to Julian Brost for reporting the issue and testing, and to Federico
G. Schwindt <fgsch@lodoss.net> for helping to debug it!
* bug153-ServerMask:
Update irc-info.c to use irc-macros.h
Add new irc-macros.h to project
irc-info.c: add/streamline function documentation comments
irc-info: move static functions at the top of the file
Implement new function Client_SearchServer()
Conflicts:
src/ngircd/irc-info.c
Test if the user that it is to be kicked is on the channel before user
channel modes are tested. Otherwise assert( cl2chan != NULL ); in
line 742 would fail and stop the service.
This fixes the following warning using Apple LLVM version 4.2
(clang-425.0.24) on OS X:
src/ngircd/conn.c:157:9: Implicit conversion loses integer
precision: 'long' to 'int'
The "@" character isn't allowed in IRC usernames, because it is the
separator between user name and hostname in IRC masks:
<nickname>!<username>@<hostname>
This patch accepts user names including "@" characters, saves the
unmodified name for authentication but stores only the part in front
of the "@" character as "IRC user name". And the latter is how
ircd2.11, Bahamut, and irc-seven behave as well.
Closes bug #155.
* systemd:
ngircd.sock: explicitely bind to IPv4 and IPv6 addresses
Show address and port of sockets passed-in by systemd(8)
Check type of sockets passed-in by systemd(8)
Adjust severity levels of some log messages
New configuration option "IdleTimeout": exit daemon when idle
Implement support for systemd(8) "socket activation"
contrib/README: add more files
This patch makes sure that ngIRCd doesn't try to handle sockets of
unsupported types, for example of AF_INET6 sockets when ngIRCd isn't
compiled with support for IPv6 ...
This includes:
- move IRC_SetPenalty() at the beginning of the handler functions,
- use macros provided by irc-macros.h,
- code cleanup.
The main benefits of this patch are core size reduction, streamlined
structure of the handler functions, and enhanced functionality:
because of the _IRC_GET_TARGET_SERVER_OR_RETURN_() macro using the
Client_SearchServer() function, the target of the specific IRC command
can now be given server names, server mask, or the nickname of a user
connected to the server.
Closes bug #153.
This file prvides some macros for common tasks required by functions
implementing handlers for IRC commands:
* _IRC_ARGC_LE_OR_RETURN_
* _IRC_ARGC_GE_OR_RETURN_
* _IRC_GET_SENDER_OR_RETURN_
* _IRC_GET_TARGET_SERVER_OR_RETURN_
Add missing comments, streamline wording, and remove references to the
RFCs: this will be added to ./doc/Commands.txt with an other patch and
we want to avoid redundancy ...
Use the currently "displayed hostname" (which can be cloaked!) for
hostname matching, not the real one. In other words: don't display
all the cloaked users on a specific real hostname!
Thanks to DNS <dns@rbose.org> for reporting this issue.
This function returns the server structure of a client or a given "mask";
it is useful for implemention handlers for commands like "COMMAND *.net",
which should work on a server matching "*.net".
Please note that the local server is always returned when it matches the
mask, but besides that, the order is completely arbitrary.
This patch implements a new configuration option "IdleTimeout" in the
[Limits] section of the configuration file which can be used to set a
timeout (in seconds) after which the whole daemon will shutdown when no
more connections are left active after handling at least one client.
The default is 0, "never".
This can be useful for testing or when ngIRCd is started using "socket
activation" with systemd(8), for example.
This patch enables ngIRCd to work with listening sockets already
initialized and passed-in by systemd(8) and hereby to support on-demand
"socket activation".
systemd(8) uses two environment variables to pass information about the
sockets to ngIRCd, LISTEN_PID and LISTEN_FDS, and this mechanism only
kicks in when both variables are set. In all other cases, and therefore
in most installations out there, nothing changes at all.
Please note:
If socket activation is in effect, ngIRCd will not initialize any (other)
soeckets on its own! All sockets must be configured in the systemd(8)
socket unit configuration file in this case, see ./contrib/ngircd.socket
for example.
Probably it would be interesting to match passed-in sockets to configured
listening sockets and to initialize all the remaining ones not already
set up by systemd(8), but this is kept back for an other patch ...
See
- <http://0pointer.de/blog/projects/socket-activation.html>
- <http://0pointer.de/blog/projects/socket-activation2.html>
- <http://www.freedesktop.org/software/systemd/man/systemd.socket.html>
This patch introduces the new numeric 310(RPL_WHOISSERVICE) and enables
WHOIS to display information about IRC services. This numeric is used
for this purpose by InspIRCd, for example -- but as usual, other numerics
are in use, too, like 613 in UltimateIRCd ...
Please note that neither the Operator (+o) not the "bot status" (+B)
of an IRC service id displayed in the output.
Change suggested by Federico G. Schwindt <fgsch@lodoss.net>, Thanks.
This fixes the following warning, at least on OpenBSD 4.8:
irc-info.o(.text+0x2427): In function `IRC_WHO':
src/ngircd/irc-info.c:896: warning: strcpy() is almost always misused,
please use strlcpy()
Make sure that all log messages end with a correct punctuation mark.
The rules for formatting log messages are:
1. Add punctuation marks to all messages passed to the actual logging
functions like Log() and LogDebug().
2. Don't add any punctuation marks to messages that are stored in
variables for later use or are passed over the network.
3. IP addresses, DNS host names and IRC server names should be quoted.
4. Messages originating in the network should be quoted (at least if
they are "untrusted" or variable).
Most probably this patch doesn't fix all mistakes, but it should be a
good starting point ...
Now ngIRCd returns a more specific error message for numeric
ERR_NOTREGISTERED(451) when a regular user tries to use a command that
isn't allowed for users but for servers: ERR_NOTREGISTEREDSERVER(451).
Don't report ERR_NEEDMOREPARAMS(461) when a MDOE command with more modes
than nicknames is handled, as well as for channel limit and key changes
without specifying the limit or key parameters.
This is how a lot (all?) other IRC servers behave, including ircd2.11,
InspIRCd, and ircd-seven. And because of clients (tested with Textual and
mIRC) sending bogus MODE commands like "MODE -ooo nick", end-users got the
expected result as well as correct but misleading error messages ...
If ngIRCd is compiled using "strict mode", these errors are still reported.
Reported-by: Tim <tim@stackwatch.net>
This patch introduces the new function Conf_SSLInUse() to check when the
current server configuration requires the SSL subsystem to be initialized
and accounts incoming as well as outgoing connections -- so this fixes
commit bb20aeb9 ("Initialize SSL when needed only, and disable SSL on
errors") which only handled the inbound case ...
Tested-by: Brett Smith <brett@w3.org>
* bug145-ProvideHelp:
Use "${docdir}/Commands.txt" as help text file
Add a note that "help file" is updated on startup and REHASH only
Add doc/Commands.txt which should document all commands
Implement Help() function parsing and returning the help text
Document "HelpFile" in sample-ngircd.conf and ngircd.conf.5
Implement new configuration option "HelpFile"
IRC_HELP(): Code cleanup
Refactor Read_Motd() into Read_TextFile()
This function parses the already read in help text and sends the requested
portions to the user. Parsing is done as following when a user user
issues a "HELP <cmd>" command:
1. Search the file for a line "- <cmd>",
2. Output all subsequent lines that start with a TAB (ASCII 9) character
to the client using NOTICE commands, treat lines containing a single "."
after the TAB as empty lines.
3. Break at the first line not starting with a TAB character.
This format allows to have information to each command stored in this file
which will not be sent to an IRC user requesting help which enables us to
have additional annotations stored here which further describe the origin,
implementation details, or limits of the specific command.
A special "Intro" block is returned to the user when the HELP command is
used without a command name.
This new configuration option allows to specify a specially formatted
text file which can be used by the HELP command to provide information
about the commands and their syntaxes.
Only check the channel user modes of the initiator if he is joined to
this channel and not an IRC operator enforcing modes (which requires
the configuration option "OperCanUseMode" to be enabled), because trying
to check channel user modes of a non-member results in this assertion:
Assertion failed: (cl2chan != NULL), function Channel_UserModes,
file channel.c, line 742.
This closes bug #147, thanks to James Kirwill <james.kirwill@bk.ru>
for tracking this down!
This fixes the following warning messages of gcc 4.5.3 on Cygwin when
building with debug code enabled:
ng_ipaddr.c: In function ‘ng_ipaddr_init’:
ng_ipaddr.c:52:2: warning: comparison between signed and
unsigned integer expressions
ng_ipaddr.c:53:20: warning: comparison between signed and
unsigned integer expressions
resolve.c: In function ‘ForwardLookup’:
resolve.c:271:3: warning: comparison between signed and
unsigned integer expressions
This fixes the following warning message of 4.5.3 on Cygwin:
resolve.c: In function ‘ForwardLookup’:
resolve.c:273:21: warning: comparison between signed and
unsigned integer expressions
Now ngIRCd uses two fields internally, one to store the "real" hostname
and one to save the "cloaked" hostname. And both fields can be set
independently using the "METADATA host" and "METADATA cloakhost" commands.
This allows "foreign servers" (aka "IRC services") to alter the real and
cloaked hostnames of clients without problems, even when the user itself
issues additional "MODE +x" and "MODE -x" commands.
This fixes a few warnings of this type:
XXX.c: In function 'AAA':
XXX.c:YY: warning: array subscription has type 'char'
Tested on NetBSD 5.0.2 with gcc 4.1.3.
This is correctly handled by ipaddr/ng_ipaddr.h today, and the check
in tool.h isn't required any more -- and caused errors on OpenBSD 5.0:
In file included from ./../tool/tool.h:23:
/usr/include/arpa/inet.h:74:
warning: "struct in_addr" declared inside parameter list
This flag indicates, that the server supports the enhanced "xop channel
user modes", like channel owner, admin, and halfop. This information is
used to make sure that no unsupported CHANINFO commands are sent to
servers not supporting such mode prefixes, for example.
Use "METADATA host" commands to let servers supporting this command
know which (possibly cloaked) hostname is in effect for a specific
client. This prevents "double cloaking" of hostnames and even cloaked
hostnames are in sync on all servers supporting "METADATA" now.
A client for which a METADATA command has been received from one of
its peers got the client flag "M" set. So it's safe to assume that
such a client gets "METADATA host" commands for its cloaked hostname
and the server must not cloak the hostname on its own, even when the
client mode "+x" is set.
The METADATA command can be used by other servers to update "metadata"
of registered clients, like the client info text ("real name"), user
name, and hostname:
:<prefix> METADATA <target> <key> :<value>
It is distributed in the network, unknown <key> names are silently ignored
and passed on, too. This allows for further extensions.
If PredefChannelsOnly is enabled, and if someone tries to create
a channel which does not exist, then the error message is a 474.
The 474 Error message changed recently and does not match anymore:
'Cannot join channel (+b) -- You are banned'.
Changed the error message to numeric 403 'No such channel'.
Bug introduced by commit 9a82304a.
(cherry picked from commit 2c2e08f34187a33c1da745995c5f213e33a91410)
Now NICK commands are always generated using the prefix of the target
user, even when the nickname change has been initiated by some other
(pseudo) server or using the SVSNICK command. In this case, the prefix
of the initiator has been used, but this isn't compatible with clients
(at least weechat and irssi don't handle such NICK commands correctly).
The SVSNICK command allows other servers (and services on
"pseudo-servers") to forcefully change nicknames of remote users.
Syntax: ":<from> SVSNICK <oldnick> <newnick>"
The SVSNICK command itself doesn't change the nickname, but it becomes
forwarded to the server to which the user is connected to. And then this
server initiates the real nickname changing using regular NICK commands.
This allows to still run networks with old servers not supporting the
SVSNICK command, because SVSNICK commands for nicknames on such servers
are silently ignored and don't cause a desync of the network.
This reverts a not intentional code change and fixes the following compiler
warning message (tested with gcc 4.4.5):
irc-server.c: In function "IRC_SERVER":
irc-server.c:142: warning: suggest parentheses around operand of "!"
or change "&" to "&&" or "!" to "~"
Add randomly up to 15 seconds to the reconnect delay for outgoing server
links when the connection has been "short" and therefore the "ConnectRetry"
delay is being enforced.
This should make it even more unlikely that two servers deadlock each
other when both are trying to connect to the other one at the same time,
for example in test environments.
If two servers try to link each other, there was a time frame that
could result in one connection overwriting the other, e. g. the incoming
connection overwriting the status of the outgoing one. And this could
lead to all kind of weirdness (even crashes!) later on.
So now such incoming connections are dropped. But this most probably
prevents the two servers from linking until timing changes somehow
(network latency?) because each server drops the incoming connection of
the other one, so no connection survives in the end.
But this has to be addressed by an other patch ...
This is how ngIRCd up to release 19.2 behaved; "bug" introduced by commit
67e882, "configure.in: require autoconf 2.67 and automake 1.11", which
changed the "PACKAGE_NAME" to "ngIRCd"; so use "PACKAGE" which still is
the lowercase version for initializing syslog logging.
Remote servers are always allowed to change all channel topics,
and IRC Operators are allowed to change all channel topics if the
configuration option "OperCanUseMode" is enabled.
Bug introduced by commit 7b01bb8 and reported by DNS777.
Currntly ngIRCd supports 13 user and 15 channel modes, because there
have been quite a few additions since our last release. But our data
structures can only hold 15 user and -- even worse! -- only 9 channel
modes! So enlarge the buffers to 20 bytes (actually 21 including NULL)
to allow storing of all mode characters and to have some space left
for more modes to come ...
(cherry picked from commit 8996d777621d88d4bcc439ab4792b2814920687f)
Replaced error message for channel mode +M with ERR_NEEDREGGEDNICK_MSG
(used by Bahamut, inspircd, ircu & Unreal too) and using numeric 477
and the msg simliar like inspircd.
Replaced the error message ERR_CANNOTSENDTONICK_MSG for user mode +b
with ERR_NONONREG_MSG and using numeric 486, similar like unrealircd.
(cherry picked from commit 55a61ab17f63a9e757b7c7598c31b98ce5a132e8
and commit 3737d9ab7da1ea0485cefc07c65dc5308bf0db02)
Don't abort on "single user operating systems" that don't know more than
one user account and therefore can't change user and group IDs.
Currently, the only such system supported by ngIRCd is Haiku, a BeOS
clone.
When a user has set mode "b", all private messages and notices to this
user are blocked if they don't originate from a registered user, an IRC Op,
server or service. The originator gets an error numeric sent back in this
case, ERR_CANNOTSENDTONICK_MSG(976), which is/was(?) used by KineIRCd, too.
This closes bug #144.
This error message is not only used if one can not send to a channel
because it is moderated, but for _all_ reasons when a message can not
be delivered (moderated, banned, no external messages, ...), so strip
the "(+m) -- Moderated" part of the error message again.
Bug introduced by commit 9a82304a.
Not only show RPL_WHOISHOST_MSG to local IRC opreators, but show
it to all IRC operators in the network. And don't show it to anybody
if the "more privacy" configuration option is enabled.
This closes bug #134.
Implement numeric RPL_WHOISMODES_MSG(379) and show user modes in the
reply of the WHOIS command for the user himself or, if MorePrivacy
isn't set, for request initiated by an IRC operator.
Numeric 379 is used by Unreal and InspIRCd for this purpose, too.
Closes bug #129.
If the new channel mode "V" is set, the INVITE command becomes invalid
and all clients get the new ERR_NOINVITE_MSG(518) reply.
Unreal and InspIRCd uses this mode, too.
This closes bug #143.
This patch fixes unsetting of channel user mode "+a" (channel admin)
and adds a better error message: without this patch, a channel admin is
unable to unset this mode.
This closes bug #142.
This closes bug #109.
* bug109-CHARCONV:
Debian: require "telnet" or "telnet-ssl" for building
Debian ngircd-full[-dbg]: enable CHARCONV
Add "CHARCONV" to "feature string" when enabled
Implement new IRC+ "CHARCONV" command
Added new configure option "--with-iconv"
Conflicts:
src/ngircd/messages.h
Both modes protect users from channel kicks: only IRC operators and
servers can kick users having mode "q" or in channels with mode "Q".
Original patch by DNS777 <dns@rbose.org>, thanks!
This closes bug #141.
Patches from Federico G. Schwindt, thanks!
(cherry picked from commit a44b7126227ba1118ec02b399e31b08102af5e8c
and 6fbe9583753b2620da275676cde46a89cb4d06c2)
Allow users to "cloak" their hostname only when the configuration
variable "CloakHostModeX" (introduced in 19.2) is set. Otherwise, only
IRC opertators, other servers, and services are allowed to set mode +x.
This prevents regular users from changing their hostmask to the name
of the IRC server itself, which confused quite a few people ;-)
This fixes bug #133.
If disabled, IRC operators don't become channel operators in persistent
channels when joining. Enabled by default, which has been the behavior
of ngIRCd up to this patch.
Closes bug #135.
(Cosmetic fixes by Alex.)
As long as 'MorePrivacy' isn't enabled in the configuration file, local
IRC operators can see secret (+s) channels when using the LIST command.
Closes bug #136.
* automake-am11-am12:
autogen.sh: detect automake version format a.b.c and a.b
configure.ng: don't require GIT tree to detect version string
Include .mailmap file in distribution archives
Include all build-system files into distribution archives
Change build system to support new and old GNU automake
By Alexander Barton (5) and Sebastian Köhler (2)
* bug92-xop:
Fix NAMES/WHO response when client has multi-prefix
Fix prefix of "halfop" when "multi-prefix" is active
Clean up doc/.gitignore
doc/Modes.txt: add version number to new channel modes
Fix some "whitespace glitches"
Tests and documentation for xop
Implemented xop support
Conflicts (because of "multi-prefix fix"):
src/ngircd/irc-info.c
This fixes bug #92 "ngircd does not support XOP usermodes".
Starting with GNU automake 1.12, the "de-ANSI-fication support" has been
removed, which ngIRCd used to enable building itself on very old systems.
Now the problem is, that using automake >= 1.12 isn't working because of
the now unsupported M4 macros. Therefore the solution that this patch
implements is to dynamically generate the automake input files with our
own ./autogen.sh script:
configure.ng => configure.in
Makefile.ng => Makefile.am
This is quite an ugly approach, but it works and enables us to:
1. use current automake >= 1.12 for development and "private builds",
2. still build distribution archives using automake 1.11.x that have
"de-ANSI-fication support" enabled in the generated Makefile's.
And if you are using Makefile's generated with a automake version newer
than 1.11.x (without "de-ANSI-fication support"), the ./configure script
warns you not to use this generated build system to generate distribution
archives.
Drawback of this patch: you MUST use our autogen.sh script, you can't call
the autoconf/automake commands directly any more; but autoreconf should
still work ...
With this patch, the SSL subsystem will only be initialized if at least
one SSL ports is configured; so you won't get "SSL initialization failed"
messages if you didn't configured it at all.
And if SSL initialization fails, no SSL listen ports will be enabled
later which never could establish a working SSL connection at all ...
Update GNU autoconf and automake infrastructure.
Tested on modern systems as well as Apple A/UX :-)
* autoconf-update:
AUTOMAKE_OPTIONS: fix ansi2knr option, include path
Don't use AC_FUNC_MALLOC and AC_FUNC_REALLOC
Make our own targets "silent", if enabled
configure.in: use AC_CHECK_{FUNCS|HEADERS}_ONCE
Updated config.{guess|sub} to version 2012-08-14
Make autogen.sh more verbose when VERBOSE=1 is set
configure.in: use AC_SEARCH_LIBS (not AC_CHECK_LIB)
configure.in: use AS_HELP_STRING macro
configure.in: use AC_CANONICAL_HOST (not AC_CANONICAL_TARGET)
configure.in: inttypes.h is an optional header file
Use HAVE_SETSID #define when testing for setsid()
Don't include <stdint.h>, it is included by "portab.h"
Don't check type.h availability, it is required
configure.in: Use AC_CONFIG_FILES macro
configure.in: Don't use AC_C_PROTOTYPES
configure.in: Update checks for required and optional features
configure.in: require autoconf 2.67 and automake 1.11
configure.in: sort some lists (templates, output, ...)
This fixes the following warning message when building without SSL support:
conn.c: In function "New_Connection":
conn.c:1365: warning: unused parameter "IsSSL"
Introduced by commit 01b62202.
* 'xop' of https://github.com/kart0ffelsack/ngircd:
Tests and documentation for xop
Implemented xop support
Conflicts (because of merge of the 'cmode-M' branch):
src/ngircd/channel.c
src/ngircd/defines.h
src/ngircd/messages.h
ngIRCd is a long-running process and changes its working directory to "/" to
not block mounted filesystems and the like when running as daemon ("not in the
foreground"); therefore the path to the configuration file must be relative to
"/" (or the chroot() directory), which basically is "not relative", to ensure
that "kill -HUP" and the "REHASH" command work as expected later on.
This fixes parts of bug #127.
It makes no sense to limit the list size when doing WHO for a channel
and not to return all the users in that channel, so I removed the check.
But if there are more than MAX_RPL_WHO(25) replies, the client requesting
the list will be "penalized" one second more (then 2 in total).
This fixes bug #125.
Some systems, notably FreeBSD 4.x, do have the kqueue() function but
lack the definition of EV_SET() in their header files -- but don't
worry, we can #define it on our own ;-)
Definition taken from /usr/include/sys/event.h of FreeBSD 8.1.
Patch tested on FreeBSD 4.1 by Götz Hoffart. Thanks!
Conn_StartLogin() is called after the connection has been established and
fully innitialized, including the SSL handshake, for example.
Up to this patch, the "NoticeAuth" option broke the SSL handshake ...
This numeric is sent to the client each time it changes its displayed
hostname using "MODE +/-x", and if "CloakHost" is set right after the
MOTD has been sent.
Not only cloak the hostname in Client_MaskCloaked(), but also in
Client_HostnameCloaked() -- so move the actual cloaking to this function
and call it in Client_MaskCloaked() to get the (cloaked) hostname.
This fixes USERHOST not displaying the correctly cloaked hostname,
for example.
This patch series allows ngIRCd to support the user mode "B" ("Bot flasg"):
it is settable and unsettable by every (non-restricted) client.
According to DNS777, this is how Unreal and InspIRCd do behave, so do we :-)
By Alexander Barton (1) and DNS777 (1)
* umode-B:
Add new user mode "B" to doc/Modes.txt
Implement an Unreal-like user mode "B" ("Bot mode")
By Alexander Barton (2) and DNS777 (1)
* cmode-M:
Add new channel mode "M" to doc/Modes.txt
Remove Can_Send_To_Channel_Identified()
Implement channel mode "M"
Two fixes here: IRC_Send_NAMES was checking the capability of the
wrong client when responding, and it didn't return any prefix for
clients that had either +v or +o but not both.
By Alexander Barton (1) and DNS777 (1)
* better-chan-errors:
Remove unused ERR_CANNOTSENDTOCHAN2_MSG message
Add some more information to channel error numerics
This patch series converts the statically allocated password buffer in the
CLIENT structure into a dynamically (and only when needed) allocated buffer
which is referenced by the CONNECTION structure.
This a) saves memory for clients not using passwords at all and b) allows
for "arbitrarily" long passwords.
By Brett Smith (5) and Alexander Barton (2).
* 'move-connection-password' of git://arthur.barton.de/ngircd-alex:
Login_User(): use "conn" insted of calling Client_Conn(Client)
Free already saved password when storing a new one
Indentation and style fixes.
Connection password is not constant.
Implementation clean-ups.
Dynamically allocate memory for connection password.
Move client password from the Client to the Connection struct.
The "ServiceMask" variable in "Server" blocks now can handle more than
one mask using the new MatchCaseInsensitiveList() function.
This makes marking "service clients" much more specific, which is a
good thing per se, but which is the prerequisite for reasonably
blocking these nick names, too (see commit a6dd2e3 for details).
This patch introduces the new function Conf_NickIsBlocked() which checks
if a given nick name matches with the "service mask" of a configured server.
And Client_CheckNick() uses this information to deny such names for regular
IRC users.
So nick names intended for IRC services are more protected and can't be used
by regular users even when the "services pseudo-server" isn't connected to
the network.
But please note:
Up to now, there can be only one "ServiceMask" pattern per server, which
most probably blocks much more nick names than really required ...
So "ServiceMask" should allow more than one pattern which can be more
specific, and most probably it should be possible to block nick names in
the global server configuration as well.
Nick names introduced by other servers/services are never restricted.
This is a relatively naive implementation, basically doing the bare minimum
necessary to make the switchover go. Subsequent commits can focus on
improving the implementation.
3 new channel user modes have been added.
Half Op: +h(Prefix: %) can set the channel modes +imntvIbek
and kick all +v and normal users.
Admin: +a(Prefix: &) can set channel modes +imntvIbekoRsz and kick all
+o, +h, +v and normal users.
Owner: +q(Prefix: ~) can set channel modes +imntvIbekoRsz and kick all
+a, +o, +h, +v and normal users
Implemented support for hashed hostnames for CloakHost. The admin can
use '%x' in both the CloakHost and CloakHostModeX setting. The config
option CloakHostModeX was renamed to CloakHostSalt. This salt is used
for both cloaking options.
CloakHostModeX can now contain '%x'. It will be replace by the hash of
the original client hostname. The new config option CloakHostModeXSalt
defines the salt for the hash function. When CloakHostModeXSalt is not
set a random salt will be generated after each server restart.
Spelling fix in defines.h
Don't try to establish an outgoing server link after DNS lookup when this
server re-connected on its own in the meantime.
In addition, log a warning message if we try to update the connection
index of an already connected server structure -- and ignore it.
Up to now, both behaviour could lead to a race when the remote server
connects to this daemon while it still prepares the outgoing connection:
- The local server prepares the new outgoing connection ...
- in the meantime the remote server becomes connected and registered.
- Now the new outgoing connection overwrites the (correct) socket handle,
- then the 2nd connection becomes disconnected: "already registered",
- and the 1st connection becomes unhandled ("gets lost") because the
configuration structure is reset because of the wrong socket handle.
This patch hopefully fixes all these problems.
Only alphanumeric characters are allowed in the user name, so ignore
all IDENT replies that would violate this rule and use the one supplied
by the USER command.
Only alphanumeric characters are allowed in the user name, so terminate
the connection if any "strage" characters have been supplied by the user.
This is how other IRC daemons (like ircd2.11 and ircd-seven) behave ...
This fixes the following warnings with GCC 4.4.5 on Linux:
irc-login.c: In function ‘IRC_PASS’:
irc-login.c:92: warning: implicit declaration of function ‘strlen’
irc-login.c:92: warning: incompatible implicit declaration of built-in function ‘strlen’
irc-login.c:113: warning: incompatible implicit declaration of built-in function ‘strlen’
irc-login.c:129: warning: implicit declaration of function ‘strchr’
irc-login.c:129: warning: incompatible implicit declaration of built-in function ‘strchr’
irc-login.c:133: warning: implicit declaration of function ‘strcmp’
irc-login.c: In function ‘IRC_SERVICE’:
irc-login.c:556: warning: incompatible implicit declaration of built-in function ‘strchr’
login.c: In function ‘Login_User’:
login.c:131: warning: implicit declaration of function ‘strcmp’
* capabilities:
"multi-prefix" capability 2/2: adjust NAME and WHO handlers
"multi-prefix" capability 1/2: implement complete CAP infrastructure
IRC_Send_NAMES(): Code cleanup
New function Client_CapSet() in addition to Client_Cap{Add|Del}
"CAP REQ" starts capability negotiation and delays user registration
Correctly handle "CAP END", new client type CLIENT_WAITCAPEND
Implement core IRC capability handling and "CAP" command
New "login" source file
Introduce_Client() => Client_Introduce(), and move it to client.c
Now ngIRCd is able to handle "CAP LS", "CAP REQ", "CAP LIST", and
"CAP CLEAR" commands.
"multi-prefix" can be set/unset, but has no functionality - yet!
This fixes the following warning of clang:
/src/ngircd/lists.c:152:44:
warning: size argument in 'strlcpy' call appears to be size of the
source; expected the size of the destination [-Wstrlcpy-strlcat-size]
But it isn't a real problem, because the size of the source always is the
same than the size of the destination ...
This patch implements the core functions to support "IRC Capabilities"
and the IRC "CAP" command as used by other servers and specified here:
<http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html>.
It enables ngIRCd to support the defined handshake, but it doesn't
implement any capabilities, so "CAP LS" and "CAP LIST" always return
the empty set and "CAP REQ ..." always fails with "CAP NAK".
Rename Hello_User[_PostAuth] to Login_User[_PostAuth] and move it to the
new login.c; and move cb_Read_Auth_Result(), too. This will enable further
code to easily call Login_User() when required.
Up to now, ngIRCd silently ignored permission denied errors when trying
to enable a chroot setup: only the "not running chrooted" message became
logged later on.
This patch lets ngIRCd exit with a fatal error when the chroot can't
be enabled on startup -- this is the much safer bevahiour!
This fixes the following warning with gcc 4.6.3.:
irc-mode.c: In function "Channel_Mode":
irc-mode.c:947:26: error: "list" may be used uninitialized
in this function
irc-mode.c:884:25: error: "list" may be used uninitialized
in this function
(The variable has never been used uninitialized, so don't worry)
When
* building the ngircd Debian package (on Linux at least) and
* using the sbuild build system,
the command "ps -af" does not include the commands running inside the
sbuild system. Therefore, start-server.sh will report a fail as getpid.sh
cannot not find the ./T-ngircd1 just started although it's actually
running. This results in a funny build log ...
starting server 1 ... failure!
FAIL: start-server1
running connect-test ... ok.
PASS: connect-test
The self-test of getpid.sh however will likely succeed as it's happy if
it sees any process with "sh" somewhere in the name. Things go downhill
from there.
The confusing things are:
* The alternative cowbuilder/pbuilder does not have this problem.
* The alternative usage "ps ax" does fine.
So, as a quick hack, the patch attached adds another switch to getpid.sh.
Start "regular" logging not until the configuration file has been read in
and "SyslolgFacility" is set, and log all configuration errors using the
generic "daemon" facility.
So if there are no configuration errors, logging starts right after parsing
the configuration and we log the configuration file used _after_ reading it.
But this is no problem because every configuration error message includes
the configuration file name as well.
(The "double hello" has been introduced by commit 3641e51109)
Syslog logging has been initialized before reading the configuraton
file, so ngIRCd always used the default facility and ignored the
"SyslogFacility" configuration option.
Thanks to Patrik Schindler for reporting this issue!
