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.
Starting with Anope 1.9.8, the ngIRCd protocol module is included in the
Anope distribution, so there's no longer any need to support our own (but
now heavily outdated!) patches. Therefore remove them.
Starting with Anope 1.9.8, the ngIRCd protocol module is rewritten from
scratch by "DukePyrolator" and included in the Anope distribution. So no
patching is required any more, yeah!
Drawback: Anope 1.9.8 is in development and not yet released ...
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.
This fixes
automake-1.12/am/library.am: warning: 'libngipaddr.a':
linking libraries using a non-POSIX .../automake-1.12/am/library.am:
archiver requires 'AM_PROG_AR' in 'configure.in'
src/ipaddr/Makefile.am:12: while processing library 'libngipaddr.a'
and similar warnings of automake.
* 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
Now ngIRCd requires at least GNU autoconf 2.61 and automake 1.10, the
requirements of commit 67e882d4 have been too restrictive:
19.2 67e882d4 now
---------- --------- --------- ---------
autoconf >=2.50 >=2.67 >=2.61
automake >=1.6 >=1.11 >=1.10
The tools required now are supported by Debian GNU/Linux 4.0 "Etch",
RedHat Enterprise Linux 5, and Mac OS X 10.6.x for example.
I read the changelogs of autoconf and automake, and I think ther's nothing
that prevents it from working with these older versions; and we don't want
to force users to upgrade without real benefits.
Please note: the recommended versions are still autoconf 1.11.x and the
most recent autoconf release that works with automake 1.11.x!
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 ...
The iconv library should be used for implementing the new CHARCONV
IRC command discussed in bug 109.
And because CHARCONV will be an IRC+ feature, we only test for libiconv
if IRC+ is enabled as well.
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, ...)
We don't expect the GNU'ish behaviour of of malloc() and realloc() and never
implemented the replacement functions rpl_malloc()/rpl_realloc() -- so these
test result in linking failues on systems that don't have a GNU'ish malloc()
and realloc() even though we don't require it!
Introduced by commit 47ad9afc.
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.
Now "make uninstall" removes the installed "ngircd.conf" file, if it
is still equal to our "sample-ngircd.conf" file and therefore hasn't
been modified by the user. If it has been modified, it isn't removed
and a notice is displayed to the user.
In addition, "make install" now displays a message when no ngircd.conf
file exists and the "sample-ngircd.conf" file will be installed as a
starting point.
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
* bug124-CloakHostModeX:
Describe "CloakHostModeX" in sample-ngircd.conf an ngircd.conf(5)
Rename "CloakModeHost" option to "CloakHostModeX"
Introduce new configuration option "CloakModeHost"
This closes bug #124.
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’
* 'master' of /srv/git/ngircd:
"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
Xcode: update project file for Xcode 4.3
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
* 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!
This patch updates the limits for handling commands from a remote server:
- "<user count> / 5 + <min>" using "<min>=10" during normal operation,
- the above count multiplied with 5 while servers are syncing.
The intention is to a) make the limit dependent of the number of users
in the network (the more users, the more commands required to sync) and
b) to significantly rise this limit while servers are joining the network
to make the login and synchronization faster.
At the end of sending all "state" to the remote server, a PING command
is sent to request a PONG reply. Until then, no "regual" PING was sent,
so Conn_LastPing(<connection>) is null and now becomes non-null in the
PONG command handler.
So the servers are still synchronizing when Conn_LastPing(<connection>)
is 0, which could easily be tested.
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
On Mac OS X 10.7 Lion, this fixes
In file included from .../contrib/MacOSX/../../src/ngircd/client.c:28:
/Developer/SDKs/MacOSX10.7.sdk/usr/include/netdb.h:272:13:
error: expected identifier or '('
The default of "PAM" is "yes" when ngIRCd has been configured to use it,
so show the correct default value in the sample configuration file.
Closes#119.
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]
Xcode requires Mac OS X 10.6 or newer; Xcode 4 supports this project
format as well, so effectively you can use Mac OS X 10.6.x or 10.7.x
for building ngIRCd with the Apple Xcode IDE.
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.
* newconfig:
sample-ngircd.conf: "SyslogFacility" should be commented out
Move SSL-related configuration variables to new [SSL] section
CheckFileReadable(): only check when a filename is given ...
PAM: make clear which "Password" config option is ignored
Really remove [Features] in our manual pages
INSTALL: document changed location of configuration variables
Update sample config file and manual page for new config structure
Testsuite: update configuration files for new config file format
Display configuration errors more prominent on "--configtest"
conf.c: code cleanup
Check for redability of SSL-related files like for MOTD file
Restructure ngIRCd configuration, introduce [Limits] and [Options]
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.
* 'master' of git://arthur.barton.de/ngircd-alex:
Do reverse lookups using the AF of the incoming connection
resolve: fix reverse lookups of client connections with ConnectIPv6=no
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.
Update Mac OS X Installer.app description bundle, so that the ngIRCd
package can only be installed on the root volume ("/"); and make sure
that all installed files and directories have correct ownership and
permissions.
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.
* NoticeAuth:
Add documentation for "NoticeAuth" configuration option
Configuration: move "NoticeAuth" to GLOBAL section
New configuration option "NoticeAuth": send NOTICE AUTH on connect
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.
* CloakUserHost:
Add a note not to use a percent sign ("%") in CloakHost variable
Rename ClientHost to CloakHost, and ClientUserNick to CloakUserToNick
Don't use "the.net" in sample-ngircd.conf, use "example.net"
ngircd.conf.5: document "ClientHost" and "ClientUserNick"
Move "ClientHost" and "ClientUserNick" to end of [Global] section
ClientUserNick setting
ClientHost setting
* QuitOnHTTP:
Only "handle" HTTP commands on unregistered connections
Don't use IRC_QUIT_HTTP() if STRICT_RFC is #define'd
IRC_QUIT_HTTP(): enhance error message
Move IRC_QUIT_HTTP() below IRC_QUIT()
quit on HTTP commands: GET & POST
* bug72-WHOIS-List:
Add "whois-test" to testsuite and distribution archive
Add support for up to 3 targets in WHOIS queries.
The percent sign is reserved for future extensions, for example to
expand some variables like %H to a hash value of the real host name ...
Idea by kaFux in #ngircd.
also allow up to one wildcard query from local hosts.
Follows ircd 2.10 implementation rather than RFC 2812.
At most 10 entries are returned per wildcard expansion.
WHOIS test cases by Dana Dahlstrom.
Describe the possible types of variables in ngircd.conf:
booleans, text strings, integer numbers.
And add type information to each variable description.
previously, any client could join in this configuration:
[Channel]
Name = #test
Modes = tnk
KeyFile = /tmp/foobar
fix this by checking for zero-length key before comparing
key to channel key.
This fixes the followin GCC warning on modern Linux systems as well:
irc-login.c: In function ‘Hello_User’:
irc-login.c:876: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
This patch
- makes the server write buffer bigger: 64k,
- makes the regular write buffer bigger: 32k,
- tries to flush the write buffer starting at 4K.
Before this patch, a client got disconnected if the buffer flushing at 4k
failed, now regular clients can store up to 32k and servers up 64k even
if flushing is not possible at the moment (e.g. on slow links).
Don't do a NULL-pointer dereference when a remote server using the
IRC+ protocol sends an invalid PASS command without the required
<serverversion> parameter ...
Port number 0 marks remote servers that try to connect to this
daemon, but where this daemon never tries to establis a connection
on its own: only incoming connections are allowed.
Don't use isdigit() function any more, because it only checks the
first character of the variable value and because it doesn't know
about the minus sign which is required e.g. for "Group = -1".
The MOTD file is read in Read_Config(), so don't read it when handling
the "MotdFile" configuration variable. Instead make sure that it is
initialized properly when (re-)reading the configuration.
Fix commit 5a34bb203a:
It is not enough to strip the "No" prefix from "Ident" and "PAM",
but we have to introduce the new [Features] section to fix all
warning messages of ngIRCd.
Variables "Ident" and "PAM" in [Global] are completely wrong :-(
This enables other servers, services and IRC operators to change
channel topics, even when the client is not joined to this channel.
Now the handler for TOPIC behaves like the one for MODE.
This generic function tests if a client is allowed to do administrative
tasks to a specific channel:
- servers and services are always truested ("allowed everything"),
- channel operators are allowed,
- IRC operarors are allowed if OperCanUseMode is set in the config.
libc should know better than us.
Also, this helps debugging with tools like valgrind:
When you allocate an array of size x, and then erronoulsy
use x+1 valgrind cannot detect the bug because due to ALIGN_()
made by array.c we might have allocated more than size x...
ngircd unfortunately uses several options using double-negation, e.g.
NoIdent = No, NoPam = No, etc.
This renames all options by dropping the "No" prefix, e.g.
"NoIdent = no" becomes "Ident = yes".
The old options will continue to work, but will cause a warning
message.
Also update man pages and default config.
To prevent silly
'Ident = yes' from appearing in --configtest output in the
'ident support not compiled in and Ident Option not used' case,
make default value depend on feature availability.
If feature is available, enable by default, otherwise disable.
We might consider moving these options to a new
[Feature]
section, or something like that, because none of these options are
essential.
Another possible improvement:
'Ident = yes' option in ngircd.conf causes a warning if ngircd was
built without ident support.
This does not happen with e.g. zeroconf....
Configuration variables "MotdFile" and "MotdPhrase" are mutually
exclusive; so don't display content in both of them when running
"ngircd --configtest": instead remember which one is beeing used.
The information written to the "error file" (/tmp/ngircd-<PID>.err) when
ngIRCd is compiled with debug code enabled isn't that usefule, so don't
create this file at all.
- Add generated sample-ngircd.conf to new .gitignore file,
- refactor Makefile.am to generate sample-ngircd.conf on "make all",
to clean it up on "make clean", and to install it to the correct place.
- Make sure path names in sample-ngircd.conf are separated by "/".
If a hostname resolves to more than one IP address (round-robin DNS,
IPv4 and IPv6) and an attempt to connect to the first address fails,
ngIRCd should try to connect to the 2nd address, 3rd address etc.
But because of a wrong variable used in the call to New_Server(),
the wrong server structure has been used in further connection attemps
which possibly lead to connection attempts to already connected servers.
This is required for backwards compatibility when installing the -full
or -full-dbg package variant: PAM is enabled now but no configuration
present, so all login attempts would be denied ...
Creating /etc/pam.d/ngircd including "auth required pam_permit.so"
restores the old behaviour of allowing all connections.
disable pam_fail_delay() only is available starting with Mac
OS X 10.6; but we use the 10.5 SDK for campatibility, so don't use
this function at all when building using Xcode.
Now the ngIRCd release/version number is deduced from the "current"
annotated GIT tag; see "git describe --help" for details. This is the
same scheme the Linux kernel uses and gives much more details version
numbers for interim releases and inofficial source archives generated
using "make dist".
Please note: the version number is only updated it the autogen.sh
script is run; so after pulling in and pushing out new commits, you
should run ./autogen.sh!
This allows to compile ngIRCd using a pre-ANSI K&R C compiler again:
all source files are automatically converted by the included ansi2knr
program (of GNU automake/autoconf) before compiling them with the
K&R C compiler, but a few coding standards must be met.
Tested on Apple A/UX 3.x.
Regression testing on Linux and Mac OS X.
If ngIRCd is compiled to register its services using ZeroConf (e.g. using
Howl, Avahi or on Mac OS X) this parameter can be used to disable service
registration at runtime.
This fixes the following gcc compiler warning:
tool.c: In function 'ngt_SyslogFacilityName':
tool.c:195: warning: return discards qualifiers from pointer target type
The new option "SyslogFacility" deines the syslog "facility" to which
ngIRCd should send log messages.
Possible values are system dependant, but most probably "auth", "daemon",
"user" and "local1" through "local7" are possible values; see syslog(3).
Default is "local5" for historical reasons.
These both functions translate syslog facility names to ID numbers
and vice versa. On systems that don't define the facilitynames[] array
in syslog.h, we try to build one ourself.
This fixes the following gcc warning, emitted by Xcode:
src/ngircd/sighandlers.c: In function 'Signal_Callback':
src/ngircd/sighandlers.c:239: warning: implicit conversion shortens 64-bit value into a 32-bit value
Signals_Init() must only be called once.
This does not affect any ngircd release version.
Earlier version of this patch moved the io and sighandler
initialization before the while() loop, but as Alexander
Barton noticed that broke all systems without builtin select
support in io.c...
- declare signals_catch[] array not between the function implementations.
- rename now local function NGIRCd_Rehash() to Rehash().
- remove empty and therefore not used "catch SIGHUP; break;".
This patch allows ngIRCd to dump its internal state (connected clients,
actual configuration) when compiled with --enable-debug. The daemon
catches two more signals:
- SIGUSR1: toggle debug mode (on/off),
- SIGUSR2: dump internal state to console/syslog.
now that the main signal handling is done from the dispatcher
loop we can call NGIRCD_Rehash() directly.
the /REHASH handler can queue the Rehash() function for
execution by sending a SIGHUP. It will be run when we
return back to the dispatch loop.
Allows to defer/queue signal processing for execution on the next
event dispatch call, i.e. we can perform any signal action in
normal, non-signal context.
Example uses:
- Reload everything on HUP without writing a global "SIGHUP_received"
variable
- Dump status of internal Lists on SIGUSR1, etc.
Fix synchronization of established connections and configured server
structures after a configuration update:
- Not only test servers that already have a connection, but also check
and update configured servers to which a new connection is beeing
established (SERVER_WAIT state).
- And do the server name comparision case-insensitive.
Let CheckServers() not only skip servers that already have a
connection, but also skip servers to which a new connection is
already beeing established (SERVER_WAIT state).
This fixes PING-PONG lag calculation (which resulted in "0" before).
The "lastping" time is still reset it if a time shift backwards has
been detected to prevent the daemon from miscalculating ping timeouts.
When a client has user mode "x" set, its real hostname is cloaked
by substituting it with the server name (as configured in ngircd.conf).
Restricted clients (user mode "r") aren't allowed to change mode "x".
Please note that hostname cloaking is only in effect in server-client
communication! The server still uses the real hostname for its own
logging and for all server-server communication -- therefore all servers
in the network must support user mode "x" to prevent older servers
from leaking the real hostname of a cloaked client!
These two functions return the cloaked hostname, if the client has
enabled hostname cloaking indicated by the -- still to implement --
user mode "x". See furter patches :-)
previously, the given MotdFile file was read whenever a client
requested it.
Change handling to read the MotdFile contents into memory once
during config file parsing.
Two side effects:
- changes to the MOTD file do not have any effect until ngircds
configuration is reloaded
- MOTD file does no longer have to reside in the chroot directory
(the MOTD contents will then not be re-read on reload in that case)
This avoids a race and potentionally killing the wrong process on
systems that use randomized process IDs; now the child itself is
responsible to exit in a timely manner using SIGALRM.
Some variables are only used when compiling with IDENT or PAM support
or when the debug code is enabled. Mark them as "unused" so that gcc
doesn't generate warnings when neither of these options is enabled.
When the "NoPAM" configuration option is set and ngIRCd is compiled
with support for PAM, ngIRCd will not call any PAM functions: all
connection attemps without password will succeed instead and all
connection attemps with password will fail.
If ngIRCd is compiled without PAM support, this option is a dummy
option and nothing changes: the global server password will still be
in effect.
For each client connection a child process is forked which handles the
actual PAM authentication and reports the result back to the master
process using a pipe for communication.
While the PAM authentication is in process the daemon does not block.
The Client_SetOrigUser() function is used to store the peer-provided
user name (see USER command) in its original form, not changed by
IDENT results, for example.
Rename Log_Init_Resolver, Log_Exit_Resolver, and Log_Resolver to
Log_Init_Subprocess, Log_Exit_Subprocess, and Log_Subprocess and
make it more generic thereby.
The logic isn't as described in the source and intended by this code:
ngIRCd doesn't wait for the asynchronous resolver process until the set
penalty time is over, but until the forked process terminates or the
initial connection timeout (= PongTimeout) triggers.
So don't set the penalty time at all and remove the wrong comment.
We want to use this process status variable not only for the
resolver subprocesses but other asynchronous tasks as well;
so let's name it more generic.
The new "module" proc.c is used for functions dealing with child
processes. At the moment, it is only used by the asynchronous resolver.
All the functions already implemented habe been migrated from the
resolver code base, and the rest of the ngIRCd source code has been
adepted to the new namespace and calling conventions.
The goal is to develop "generic" process handling functions that can
be used for other purposes as well, e.g. running processes on client
connects etc.
The wrongly placed #endif lead to the following compiler warnings:
conn.h:125: warning: redundant redeclaration of ‘Conn_Count’
conn.h:125: warning: previous declaration of ‘Conn_Count’ was here
conn.h:126: warning: redundant redeclaration of ‘Conn_CountMax’
conn.h:126: warning: previous declaration of ‘Conn_CountMax’ was here
conn.h:127: warning: redundant redeclaration of ‘Conn_CountAccepted’
conn.h:127: warning: previous declaration of ‘Conn_CountAccepted’ was here
Users having the user mode "c" set receive NOTICE messages on each
new client connection to the local server as well as disconnects.
Only IRC operators (users having the mode "o" set) are allowed to
set the 'c' user mode.
These connect/disconnect messages can be useful for open proxy
scanners -- BOPM (http://wiki.blitzed.org/BOPM) is now functional
with ngIRCd, for example.
"I've been wanting this for years and finally took the 5 minutes to
patch it in. I took the response code (275) from whatever's running
OFTC's IRC network."
-- Neale Pickett <neale@woozle.org>, Fri, 11 Jun 2010 17:32:41 -0500
(OFTC is running Hybrid ircd.)
from bugzilla #105:
"ngircd-16 works great under openbsd4.7/i386, but it segfaults on
openbsd4.7/amd64."
Caused by missing function prototypes and the resulting truncation of
pointer to int.
Lets try to catch these bugs during compilation instead of SIGSEGV.
It is not possible to call Conn_Close() after Client_Destroy() has been
called, because Conn_Close wants to access the CLIENT structure which
then has been freed already.
Fix IRC_KILL to use Conn_Close() for local clients and Client_Destroy()
for remote clients only (and never both).
When we get there then the ssl handshake has failed, or
we could not create a ssl context because ssl library
initialization failed on startup.
Reflect that in the log message.
When ngIRCd restarts, all the connection counters are preserved now,
as well as the command counters for example.
It's unclear if resetting or not resetting is the "correct" behaviour,
but it's quite clear that the behaviour should be consistent for all the
counters ngIRCd uses ...
And initializing "WCounter", the global but temporary write counter,
is not necessarry at all: it is initialized (reset) before its use in
the command parser (see parse.c).
The RPL_STATSCONN numeric (250) displays information about the
highest simoultaneous connection count and the number of all
accepted connections since the daemon started up.
Used by ircd-Hybrid, Bahamut, and Unreal for example.
This patch enables ngIRCd to count the highest maximum simultaneous
connections and all the connections accepted since startup.
New functions:
- Conn_Count(): get current connections
- Conn_CountMax(): maximum simultaneous connections
- Conn_CountAccepted(): number of connections accepted
This solves warning messages of autoconf on e.g. FreeBSD 8:
configure: WARNING: netinet/ip.h: present but cannot be compiled
configure: WARNING: netinet/ip.h: check for missing prerequisite headers?
This fixes the following error when compiling on e.g. FreeBSD 6.x:
In file included from conn.c:40:
/usr/include/netinet/ip.h:160: error: syntax error before "n_long"
/usr/include/netinet/ip.h:163: error: syntax error before "n_long"
This patch fixes two warnings of gcc 4.4.3 when used with eglibc 2.11.1:
ngircd.c: In function ‘NGIRCd_Init’:
ngircd.c:801: warning: ignoring return value of ‘chdir’, declared with
attribute warn_unused_result
conn.c: In function ‘Simple_Message’:
conn.c:2041: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
The first by checking the return code and an appropriate error message,
the second by "better" ignoring it (which is correct there!) ...
dpkg-shlibdeps: warning: dependency on libnsl.so.1 [..]
(they use none of its symbols).
As shown via commit 2b14234abc
(dpkg-shlibdeps: warning: dependency on libnsl.so.1) and the
following revert of that commit, we cannot simply drop
the AC_CHECK_LIB(nsl). Although -lnsl is indeed unneeded
when glibc is used, some platforms (e.g. Solaris) need it.
Use AC_SEARCH_LIBS instead to only link when the library exports
a particular symbol.
The WEBIRC command is used by some Web-to-IRC gateways to set the correct
user name and host name of users instead of their own.
Syntax: WEBIRC <password> <username> <hostname> <ip-address>
The <password> must be set using the new configuration variable "WebircPassword" in the [Global] section of ngircd.conf.
Please note that the <ip-address> is currently not used by ngIRCd (we don't store it in the CLIENT structure, only the resolved hostname).
Only clients using a SSL encrypted connection to the server are
allowed to join such a channel.
But please note three things:
a) already joined clients are not checked when setting this mode,
b) IRC operators are always allowed to join every channel, and
c) remote clients using a server not supporting this mode are not
checked either and therefore always allowed to join.
Now the numeric 004 correctly reports all the supported user and channel
modes (user modes "r" and "w" were missing), e. g.:
:a.irc.net 004 a a.irc.net ngircd-15 aiorsw biIklmnoPstv
Fix Apple Xcode warning "cc1: warning: -Wuninitialized is not supported
without -O" when using the "Debug" build target:
Detection of uninitialized automatic variable requires data flow analsys
that is only enabled during optimized compilation.
Print "SSLOptionVar =" instead of omitting the option when
running --configtest with ssl enabled.
This better matches the behaviour of other options, e.g. ChrootDir.
This patch enables IRC Operators to use the SQUIT command as specified in
RFC 2812, section 3.1.8 "Squit".
When forwarding SQUIT commands, the server connected to the target will
drop the connection (not the target server itself!).
Please note:
- the configuration option "AllowRemoteOper" mus be enabled on the
server disconnecting the target to allow forwarding of SQUIT commands.
- if the remote server is configured to establish the connection, it
will just do this; so the disconnect is not permanent in this case!
The new "module" op.c is used to implement functions related to IRC Ops.
At the moment, these two functions are available:
- Op_Check() to check for a valid IRC Op, and
- Op_NoPrivileges() to generate "permission denied" messages.
The syntax of the CONNECT command now is:
- CONNECT <server-id>
- CONNECT <server-id> <port>
- CONNECT <server-id> <port> <target>
- CONNECT <server-id> <port> <host> <my-pwd> <peer-pwd>
- CONNECT <server-id> <port> <host> <my-pwd> <peer-pwd> <target>
Note: the configuration option "AllowRemoteOper" mus be enabled on the
target server to allow forwarding of CONNECT commands.
Added new configuration option "AllowRemoteOper" to control whether
remote IRC operators are allowed to use administrative commands that
affect this server or not
This commit introduces the configuration variable, but actually no
function is using it. That's up for the next patches to come ...
when building with debugging enabled, but without ipv6 support,
ngircd dumped core when loading a config file that specified an ipv6
listen address.
ngircd: ng_ipaddr.c:45: ng_ipaddr_init: Assertion `sizeof(*addr) >=
res0->ai_addrlen' failed.
Test for sockaddr_in.sin_len and initialize it to the correct value
which some systems (notably Mac OS X) require.
Note: this code path is only relevant when not using getaddrinfo().
Both getaddrinfo() and getnameinfo() are now used always when available, and
not only when compiling ngIRCd with support for IPv6.
This not only enables ngIRCd to handle multiple addresses per hostname when
compiled without support for IPv6, but fixes binding ngIRCd to IP addresses
on Mac OS X (and probably other BSD-based systems) as well: these systems
require that sockaddr_in is zeroed out and sockaddr_in.sin_len is set to
sizeof(sockaddr_in) like that:
src/ipaddr/ng_ipaddr.c, line 54:
assert(ip_str);
+ memset(addr, 0, sizeof *addr);
+ addr->sin4.sin_len = sizeof(addr->sin4);
addr->sin4.sin_family = AF_INET;
But this would break all the systems not using sockaddr_in.sin_len, for
example Linux -- so we assume that all these systems provide getaddrinfo()
and use that for now.
A configured server could have been removed while a connection apptempt
is still in progress. So the cb_connserver() callback has to test if the
server configuration record is still valid.
fix the following warning generated by valgrind if ipv6 is enabled:
Syscall param write(buf) points to uninitialised byte(s)
at 0x4000982: (within /lib/ld-2.9.so)
by 0x80681A8: Resolve_Name (resolve.c:477)
by 0x805439F: Conn_Handler (conn.c:1658)
by 0x804AA7C: main (ngircd.c:331)
The warning is because ng_ipaddr_t can be a union, and only the
necessary parts are initialised. The callers know what part
of the union is valid, so this is not a bug.
if more than one ip address is returned for a single host
name, ngircd is supposed to try other addresses in case
connect() to the first address returned fails for some
reason.
Alexander Barton noticed that this did not work at all,
as the additional results were not stored.
This patch fixes --with-openssl and --with-gnutls and enables both to
accept path names, so that you can use "./configure --with-XXX=/path".
All the other --with-XXX parameters support this already.
Cosmo Kastemaa reported that its impossible to create an ssl-only setup,
as ngircd binds to port 6667 by default, even if setting "Ports =".
Only add the default port if _both_ "Ports" and "SSLPorts" are
unspecified.
Fixes bugzilla #98.
Starting with GNU automake 1.11 "AM_SILENT_RULES([yes])" is available to
make the build process less verbose ("Linux 2.6 style") which helps to
spot warning and error messages.
So we use it if it is available.
This patch fixes the following silly log messages:
'ID "XXX" already registered (on connection -1)!'
If the ID is already registered on a local connection, the local
connection ID is printed; and if the ID is connected via a remote
server, "via network" is displayed.
reported on #ngircd: pasting lots of lines into a channel can kill off
many people on the channel if the read buffer is drained quickly enough
and the client-side TCP can't keep up with the incoming data.
This implements a throttling scheme:
- an irc client may send up to 3 commands per second before a one second
pause is enforced.
- an irc client may send up to 256 bytes per second before a one second
pause is enforced.
After discussion with Alexander Barton, server <-> server links are
treated specially: There is no artificial limit on the number of bytes
sent per second, and up to 10 commands are processed per second before
a pause is enforced.
It may be neccessary to make those limits tuneable to accomondate larger
networks, but for now they are compile time values.
New_Server() can call Conn_Close() in its error paths,
but that function decrements the number of current active
connections. Thus we need to increment it earlier.
When a server is running with SSL/TLS support compiled in,
it is trivial to crash the server by sending an MOTD request
via another server in the network.
- ONLY servers without ssl/tls support compiled in are not affected.
Disabling SSL in the configuration (no ssl listening ports, etc)
does NOT help.
- servers that are running standalone (i.e., not connected to any
other servers) are not affected, either.
This affects all ngircd releases since ngircd 13 (earlier versions
have no SSL/TLS support).
In addition to the "ngircd" and "ngircd-full" packages a new package named
"ngircd-full-dbg" is build: this package contains all the features of the
"full" package but includes debug code and both the --debug and --sniffer
options and the resulting binaries are _not_ stripped.
When ngircd announces the list of currently known servers
to a new (connecting) server, it sent the introducer of
the servers instead of the top server.
Assuming this network:
irc1.example.com
|--irc2.example.com
| `--irc3.example.com
| `--irc4.example.com
`--irc5.example.com
When irc4 connects to irc3, irc3 tells irc4 that irc5 was
connected to irc2. (irc2 had introduced irc5 to irc3; but thats
not what ngircd should have sent to the new server).
This also placed users on the wrong servers.
that code does not really make sense -- the info
text is freely cofngiureable and des not follow a specific
format.
Also, that "+2" might have caused invalid memory accesses.
With this patch ngIRCd displays IPv6 addresses as "[<addr>]:<port>" when
accepting new connections and later, if no successful DNS lookup could
be made (or DNS is disabled altogether).
Change VERSION to include the __DATE__ when compiling from within Xcode.
When building using "make xcode" or "make osxpkg" VERSION already is defined
to the "real" version number set in configure.in.
- PidFile, ServerUID and ServerGID are read from actual server configuration
- Exit code and behaviour is more LSB compliant
- New "status" and "test" sub-functions
Don't echo multiple syntax error messages (461) on invalid commands,
but break after the first one.
In addition, this solves corrupted 'Unknown mode "+' messages.
When using OpenSSL, the following annoying "error" message was logged whenever
an encrypted connection was shut down in a orderly fashion:
TLS/SSL Connection shutdown: ConnSSL_Read: Unable to determine error
of course, this isn't an error at all.
commit 6bc2d3d06e
(New connection option CONN_RFC1459) forgot to adjust the ssl bitmasks.
The result is that when a compressed AND encrypted server link goes down
the memory allocated by zlib and the r/w buffers are no longer
free'd as the previous ConnSSL_Free() would then also remove the CONN_ZIP flag
from the flag mask.
Store the file name of channel key files and reopen them on each access
(on each JOIN command) insted of just storing the file handles.
This eliminates the special requirements (no delete) and makes sure
that always the actual file contents are used in all circumstances.
This patch introduces the new configuration variable "KeyFile" for
[Channel] sections in ngircd.conf. Here a file can be configured for each
pre-defined channel which contains individual channel keys for different
users. This file is line-based and must have the following syntax:
<user>:<nick>:<key>
<user> and <nick> can contain the wildcard character "*".
Please not that these channel keys are only in effect, when the channel
has a regular key set using channel mode "k"!
commit 2546a13ad2
('Cumulative Message Patch') broke PRIVMSG to channels
containing dots.
Fix this by switching evaluation order:
Check first if the target matches a existing channel and only do a check
for target masks if that failed.
PRIVMSG with host/server masks is described in RFC 2812, section 3.3.1.
Makes one wonder how a server is _really_ supposed to tell the difference
between hostmasks and channel names.
Sigh.
- Change Copyright to License
- Update URL
- Make BuildRoot use %{_tmppath} macro
- Add basic BuildRequires
- Compile with zlib and openssl
- Install all docs in standard document location
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
when ngircd is build without DEBUG enabled, LOG_DEBUG messages
are always discarded.
To avoid the extra code, ngircd has a LogDebug() wrapper which
gets removed by the compiler when compiling without DEBUG defined.
Update a few functings which were using the
Log(LOG_DEBUG, .. interface directly without #ifdef DEBUG guards.
text data bss dec hex filename
127748 1900 28280 157928 268e8 ngircd.before
126836 1896 28280 157012 26554 ngircd.after
- make target "xcode" now detects the release number stored in the
configure.in file and passes it to Xcode.
- new make target "xcode-clean" which removes all files generated by
"make xcode" and removes the Xcode build directory.
Silly bug: the condition of a while() loop in the Channel_Exit() function
used the wrong variable and therefore got never executed ...
This bug is in the code since the beginning (see commit bb19cfda in 2002);
shame on me!
in the same vein as the earlier commit:
cast posix data types (pid_t, ...) to long and use
%ld as format specifier. This will avoid problems
when sizeof(int) != sizeof(type).
We could also cast to int, but this might truncate the value.
Reported by Christoph Biedl:
ngircd[21581]: Running as user irc(39), group irc(39), with PID 140733193409613.
cast pid_t to long to avoid this.
While we are there, cast uid_t and gid_t, too.
This patch fixes the following lintian(1) warning: "Manual page seems
to contain a hyphen where a minus sign was intended. '-' chars are
interpreted as hyphens (U+2010) by groff, not as minus signs (U+002D).
Since options to programs use minus signs (U+002D), this means for
example in UTF-8 locales that you cannot cut&paste options, nor search
for them easily. '-' must be escaped ('\-') to be interpreted as minus."
- Fix formatting of some log messages, mostly punctuation.
- cb_Connect_to_Server(): don't use string concatenation, because it
is not supported by pre-ANSI C compilers ...
This patch fixes the following warning of GCC (version 4.3.2) in
function pem_passwd_cb() when compiling with OpenSSL support and
without debug code:
conn-ssl.c: In function 'pem_passwd_cb':
conn-ssl.c:122: warning: unused parameter 'rwflag'
The new configuration option "NoIdent" in ngircd.conf can be used to
disable IDENT lookups even when the ngIRCd daemon is compiled with IDENT
lookups enabled.
The IRC command "SERVLIST" lists all the registered services, see RFC 2811, section 3.5.1.
The syntax is "SERVLIST [<mask> [<type>]]". The parameter <type> is not used by ngIRCd at
the moment, all registered services are of type 0 (which is the default when omitted).
ngIRCd now creates a server-local channel &SERVER with channel modes
+mnPt (moderated, no messages from outside the channel, persistent and
with the topic locked) and logs all the messages to it that a user with
mode +s ("server messages") receives.
If an IRC operator withdraws the +P ("persistent") mode and the &SERVER
channel is freed because of no members, nothing special happens. The
channel can be recerated any time later and ngIRCd would begin logging
to it again.
The following bits and bytes were not included in distribution archives:
- contrib: ngindent, ngircd.sh
- contrib/Debian: ngircd.postinst
- contrib/MacOSX: preinstall.sh, postinstall.sh
- doc/src: Doxyfile, header.inc.html, footer.inc.html, ngircd-doc.css
- src/portab: splint.h
I changed the test suite to start two test servers (on port 6789 and 6790),
so server-server links can be tested as well for which I included the new
test script "server-link-test.e".
In addition the documentation of the test suite (src/testsuite/README) has
been updated and is more complete now.
This patch lets ngIRCd count outgoing connections as well as incoming
connections (up to now only outgoing connections have been counted). This
change is required because the Conn_Close() function doesn't know whether
it closes an outgoing connection or not and therefore would decrement the
counter below zero when an outgoing connection existed -- which would
trigger an assert() call ...
Please note that this patch changes the (so far undocumented but now fixed)
behaviour of the "MaxConnections" configuration option to account the sum
of the in- and outbound connections!
Some servers send the numeric 020 ("please wait while we process your
connection") when a client connects. This is no useful information for
this server, so we simply ignore it :-)
This patch enables ngIRCd to use GNUTLS in really old versions, tested
with version 1.0.16, that don't define the "new" data types ending in
xxx_t. LIBGNUTLS_VERSION_MAJOR isn't defined there as well, so we use
it to test if we must define the new types on our own.
Alexander Barton reported a compiler warning on 64-bit platforms:
cc1: warnings being treated as errors
conn-ssl.c: In function 'ConnSSL_Init_SSL':
conn-ssl.c:403: error: cast to pointer from integer of
different size
Unfortunately, I couldn't find a real solution; the GNUTLS
API expects 'gnutls_transport_ptr_t' (which is void*),
but the default push/pull functions (send/recv) expect an int.
The only alternative solution is to pass in an address to the
file descriptor, then add send/recv wrappers that expect a pointer.
What a mess[tm].
This patch fixes the following warning of GCC (version 4.3.2) in
function ForwardLookup():
resolve.c: In function 'ForwardLookup':
resolve.c:282: warning: ISO C90 forbids specifying subobject to initialize
resolve.c:284: warning: ISO C90 forbids specifying subobject to initialize
resolve.c:285: warning: ISO C90 forbids specifying subobject to initialize
This patch fixes the following warning of GCC (version 4.3.2) in
function ConnSSL_LogCertInfo() when compiling with GNUTLS support:
conn-ssl.c: In function 'ConnSSL_LogCertInfo':
conn-ssl.c:542: warning: unused variable 'cred'
This patch
- introduces a new server flag "S" to indicate that the server can handle
the SERVICE command (on server links),
- implements the IRC command "SERVICE" for server-server links,
- uses the "SERVICE" command to announce IRC services when a new
server connects to it,
- and fixes the Send_Message() function to let it send messages to
services using a "target mask".
If the remote server doesn't indicate that it can handle the "SERVICE"
command (it has not set the "S" flag), services are announced as regular
users as before.
This patch enables ngIRCd to handle IRC services as real services, and not
as "fake users":
- Set correct client type CLIENT_SERVICE for services,
- Change log messages to include correct client type,
- PRIVMSG: allow users to send messages to services,
- Send services nick names to other servers (as users).
Please note that this patch doesn't announce services as services in the
network, but as regular users (as before). Only the local server knows
of services as services (see LUSERS command, for example). It is up to
one of the next patches to fix this and to introduce the SERVICE command
in server to server communication.
The propagation of services as regular users between servers doesn't limit
the functionality of the IRC services and will be the fallback for servers
that don't support "real" services propagation in the future.
Client_TypeText() is used to get correct naming ("Client", "Service", ...)
for log messages, and Destroy_UserOrService() is used to correctly destroy
user and services clients.
Introduce a new configuration variable "ServiceMask" in SERVER blocks to
define a mask matching nick names that should be treated as services.
Regular servers don't need this parameter (leave it empty, the default),
but you should set it to "*Serv" when connection ircservices, for example.
This patch allows ngIRCd to detect services, it doesn't change the
functionality: you only get different log messages ;-)
All the required information is already stored in the CLIENT structure
of new new connection, so pass this to Introduce_Client() and don't
invent an unneeded new structure ...
This patch allows ngIRCd to detect right after receiving the SERVER command
from the peer whether the RFC 1459 compatibility mode must be used or not.
And it fixes the announcement of users during establishing new server links
with such peers.
This patch enables ngIRCd to deal with NICK and USER commands following
RFC 1459 to register new clients, and to send these commands instead of one
full NICK command as specified in RFC 2813 on connections that are in RFC
1459 compatibility mode.
Can be useful for e. g. IRC services that simulate a RFC 1459 server.
This new connection option CONN_RFC1459 indicates that the peer on this
link only supports the IRC protocol as defined in RFC 1459 and that the
compatibility mode (e. g. for outgoing commands like NICK) should be used.
This patch allows servers and services to call the NICK command using the
syntax defined in RFC 1459 to register new users, with only two parameters.
See section 4.1.2.
Useful for some services packages, which emulate this protocol.
Config option claimed to be 'number of connections' but in reality this
was treated as 'largest file descriptor allowed'.
This also fixes another bug in New_connection, where the
ng_ipaddr_tostr_r error path was missing a return statement.
Some message targets could lead to a NULL pointer dereference and therefore
could crash the daemon (denial of service).
(cherry picked from commit e493ad2d30ff80bca2556cde2212e367cb006517)
This patch adds a new make target, "osxpkg", to the main Makefile which
gereates a Apple Mac OS X installer package of ngIRCd. The packagemaker(1)
project bundle is stored in contrib/MacOSX/ngIRCd.pmdoc.
by Steven D. Blackford <kb7sqi@aol.com>:
"I wanted to let you know that I've done a quick port of ngircd-0.12.0 for
NEXTSTEP3.3/OPENSTEP4.2. There wasn't a lot of changes required to get it
to compile clean, but I did make the necessary changes so that I didn't
have to use -posix flag. The NeXT has a pretty buggy POSIX implementation
so I always try to work around it. :-)
Anway, here's the changes required to get it to compile."
This patch fixes the following error message of GCC (tested with version
4.3.0) when not compiling ngIRCd in "strict RFC" mode:
parse.c: In function "Validate_Args":
parse.c:341: error: unused parameter "Idx"
parse.c:341: error: unused parameter "Req"
Some operating systems, for example OpenBSD and OpenSolaris, use
"localhost.<domain>" instead of just "localhost" for 127.0.0.1, so
the "message-test" using "localhost" failed on such systems.
Don't have an idee how to make this work on all platforms ... :-/
So I simply disabled the two affected tests to make the testsuite
run on OpenBSD and OpenSolaris again.
This patch fixes the following warning of GCC 4.3.1:
irc.c: In function "Send_Message":
irc.c:315: error: "lastCurrentTarget" may be used uninitialized in
this function
This closes Bug #88.
Patch proposed by Eric <egrunow@ucsd.edu>, but with wrong length
comparision: please note that Channel_IsValidName() checks the name
INCLUDING the prefix, so the test must be length<=1!
Up to this patch ngIRCd did not return any result (GIT master) or a badly
formated 403 (":irc.server 403 test :No such channel" [note the two
spaces!], branch-0-12-x) on the above commands, this patch changes the
behaviour to reflect ircd 2.11 which returns 461 in both cases.
Some operating systems, for example OpenBSD, use "localhost.<domain>"
instead of "localhost", so the "who-test" expecting "localhost" failed
on such systems.
(Please see 149859c5fecc..., which fixes this for the who-test already)
- Solaris needs both -lsocket _and_ -lnsl
- A/UX needs -lUTIL
"... which totally sucks because we'd link libnsl on Linux, too
(where its not needed at all). So, we have to figure out how to tell
autocrap to NOT put -lnsl there unless it exports a symbol we need.
This also means that [...] has to be reverted (or done properly)."
-- Florian Westphal @ #ngircd
This reverts commit 2b14234abc.
(they use none of its symbols).
So, rip out that AC_CHECK_LIB cruft, pointed out by Christoph Biedl.
If there are platforms that really need that we should
only link when we actually use these libraries.
On some systems (for example Gentoo Linux, FreeBSD, and OpenBSD), these
variables are used to select which version of GNU automake and autoconf
to use, but we shouldn't depend on a specific version -- instead we
should use the "system default". So probably it is up to the user to
set these variables accordingly to set up some wrapper scripts of his
operating system distribution.
This patch fixes the following two warnings of GCC 4.2.4:
irc-channel.c: In function "IRC_JOIN":
irc-channel.c:185:
warning: "lastkey" may be used uninitialized in this function
irc-channel.c:185:
warning: "lastchan" may be used uninitialized in this function
Up to now ngIRCd accepted CR+LF as well as a single CR or LF in "non RFC
compliant" mode (the default). But ngIRCd became confused when it received
data containing mixed line endings (e. g. "111\r222\n333\r\n").
This patch enables ngIRCd (in "non RFC compliant" mode) to detect CR+LF,
CR, and LF as equally good line termination sequences and to always end the
command after the first one detected.
Some clients (for exmaple Trilian) are that ... broken to send such mixed
line terminations ...
First patch proposed by Scott Perry <scperry@ucsd.edu>,
Thanks to Ali Shemiran <ashemira@ucsd.edu> for testing!
If ngircd receives an input line like "COMMAND arg\nIRRELEVANT\r\n",
"arg\nIRRELEVANT" is passed as an argument to COMMAND. This can lead
to output like:
:ngircd.test.server 322 nick #chan 1 :
topicwithprecedingnewline
:ngircd.test.server 322 nick #nxtchan 1 :
[..]
Worse, this allows clients to piggyback irc commands, e.g.
"TOPIC #a :test\n:fake!~a@nonexistant JOIN :#a\r\n", which
causes the client to receive a JOIN command during /LIST output.
Bug reported by Scott Perry, first patch by Florian Westphal.
In addition, the "timeout" variable has been removed because it is
unnecessary today: Handle_Buffer() handles all the data it can handle,
and io_dispatch() returns immediately when new data is available. So
we don't have to double-check but better sleep. Pointed out by Florian.
This patch does significant cleanup on the join code by using strtok_r
instead of mangling strchr to parse channel names and keys in parallel when
a JOIN command contains a list of channels and keys.
Also adds an strtok_r implementation to libportab.
Drop checks for the following C standard functions:
malloc, memmove, memset, realloc, strchr, strcspn, strerror, strstr.
Rationale: These are standard K&R/C89 functions, no point in
''making sure they exist''.
this also obsoletes ListenIPv4 and ListenIPv6 options.
If Listen is unset, it is treated as Listen="::,0.0.0.0".
Note: ListenIPv4 and ListenIPv6 options are still recognized,
but ngircd will print a warning if they are used in the config file.
Also, some plattforms require that ai_socktype
is set in the getaddrinfo() hints structure.
It is hard to test this in the test suite because we 1) shouldn't rely on
previous tests populating WHOWAS and 2) don't connect a user for more than 30
seconds.
Also makes WHOWAS return ERR_NONICKNAMEGIVEN_MSG as implied by RFC.
Some operating systems, for example OpenBSD, use "localhost.<domain>"
instead of "localhost", so the "who-test" expecting "localhost" failed
on such systems.
SERVICE, SERVLIST, and SQUERY are required by RFC 2812 (it states in
section 3 that "all commands described in this section MUST be implemented
by any server for this protocol." -- So we implement them without (much)
actual functionality ...
Brandon Beresini sent me a patch yesterday adding tests for JOIN under
various circumstances, which I believe he worked on with Bryan Caldwell
and Ali Shemiran. I made a few modifications; the result is below.
Code cleanup and fix for Bug #83, "ngIRCd chokes on 1-character messages" in
function Handle_Buffer(): the buffer is now correctly cleared when ngIRCd
receives 1-character messages terminated with either CR or LF (in violation
to RFC 2812, section 2.3 "Messages", 5th paragraph).
Modeless channels (+channels) are described in RFC 2811;
so my modifications to
530112b114
('Add support for modeless channels')
to disable +channels for --strict-rfc configurations
were wrong. This reverts those changes.
Add support for modeless channels (+channels).
[fw@strlen.de:
- integrate test cases
- don't support +channels when compiled with --strict-rfc
- do not set +o mode for channel creator
- force +nt mode when channel is created ]
The config file for ngircds test suite contained obsolete
ConfUID/ConfGID settings, causing ngircd to needlesly complain when
started as non-root (which is hopefully the _normal_ case...)
When trying to part a channel ("PART #channel") the client is not member of
the daemon now correctly reports the numeric ERR_NOTONCHANNEL (442) insted
of ERR_NOSUCHCHANNEL (403).
Added filter for GIT to ignore Xcode user preferences files (*.mode1v3 and
*.pbxuser) which are automatically generated inside the project bundle when
opened in Xcode.
client.c:72:6: warning: symbol 'Max_Users' was not declared. Should it be static?
client.c:72:21: warning: symbol 'My_Max_Users' was not declared. Should it be static?
ngircd will exit if the config file cannot be opened. While
thats okay if ngircd starts up for the first time, it isn't
when we are re-reading the config file after a /REHASH or SIGHUP.
all references to struct sockaddr/in_addr have been
removed from src/ngircd.
libngipaddr (in src/ipaddr/) hides all the gory details.
See src/ipaddr/ng_ipaddr.h for API description.
This does hit only operators that join a channel with at least 2 servers active in the net
the server the oper connects to sends "channel^Go" to the other servers
the other server first searches for the channel and then strips the modes from the channel name
he has to do the other way round: first strip and then check the channel name.
RPL_WHOREPLY messages generated by IRC_WHO don't include flags (*,@,+)
that should appear according to this description:
http://www.mishscript.de/reference/rawhelp3.htm#raw352
Other IRC servers do include the flags.
Modify who-test.e to expose missing flags,
modify ngircd-test.conf to accommodate who-test.e, and fix
irc-info.c to correct these problems.
Under some circumstances ngIRCd currently issues a channel MODE message
with a trailing space after the last parameter, which isn't permitted by
the grammar in RFC 2812 section 2.3.1:
http://tools.ietf.org/html/rfc2812#section-2.3.1
The following patch modifies mode-test.e to expose this, and modifies
irc-mode.c to correct it.
- put sending of mode and forwarding of JOIN to other clients
into seperate function.
- put sending of topic/channel names into seperate function.
- put access check into seperate function.
- translate/remove remaining german comments.
- stop if JOIN to a channel in a list (JOIN #a,#,b,#c...) fails
(This doesn't change the behaviour: skip-to-next-channel-on-error
did never work as intended)
Dana Dahlstrom reported that IRC_WHO did not follow
RFC 2812, Section 3.6.1. Specifically:
- IRC_WHO did not send "G" flag instead if "H" if client was away
- did not search username/servername/hostname etc. if argument
was not a channel.
Fix all of the above and tidy things up a bit.
Also add IRC_WHO test script contributed by Dana.
The students in my software-engineering class are writing IRC clients in
Java, and I'm running ngIRCd as a sandbox for them to play in. We
noticed ngIRCd doesn't obey the "JOIN 0" command specified in RFC 2812:
JOIN 0 ; Leave all currently joined
channels.
http://tools.ietf.org/html/rfc2812#section-3.2.1
I believe the following patch addresses this. Cheers!
[fw@strlen.de: put it into a seperate function]
parse.c:56:9: warning: symbol 'My_Commands' was not declared. Should it be static?
parse.c:107:9: warning: symbol 'My_Numerics' was not declared. Should it be static?
Also move handling of numerics into a seperate helper function.
struct Conf_Server stored the ip address to connect to
in dotted-decimal notation; but we only need this for connect()
so long-time storage isn't necessary.
- New configuration option "MaxNickLength" to specify the allowed maximum
length of user nick names. Note: must be unique in an IRC network!
- Enhanced the IRC+ protocol to support an enhanced "server handshake" and
enable server to recognice numeric 005 (ISUPPORT) and 376 (ENDOFMOTD).
See doc/Protocol.txt for details.
to the users working directory (as returned by getpwuid()).
Failing to chdir to that directory isn't an error; so
log with LOG_INFO and prefix the message with "Notice".
conn-func.h: add accessor Macros
Conn_OPTION_ADD( conn, CONN_OPTION )
Conn_OPTION_DEL( conn, CONN_OPTION )
Conn_OPTION_ISSET( conn, CONN_OPTION )
To add, remove or test for a certain option field attribute (e.g. CONN_ISCLOSING)
These Macros should be used instead of accessing conn->options directly.
- Make sure that strlcpy() returns the right value when the bufsize is 0.
- Fixed a bug in strlcat() where it would not properly detect a no-change
condition if called with an initial string longer than the specified
size limit (due to an unsigned var's inability to go negative).
Patch by Florian Westphal, <westphal@foo.fh-furtwangen.de>.
bei Bedarf bis zu einem konfigurierten Limit vergroessert.
- neue Funktionen Conn_First(), Conn_Next(), Conn_ClearFlags(), Conn_Flag()
und Conn_SetFlag().
<pkmkdocspec="1.12"><properties><title>ngIRCd</title><build>/Users/alex/Desktop/ngIRCd.mpkg</build><organization>de.barton.ngircd</organization><userSeesui="both"/><min-targetos="2"/><domainsystem="true"/></properties><distribution><versionsmin-spec="1.000000"/><scripts></scripts></distribution><description>ngIRCd – next generation Internet Relay Chat (IRC) server
daemon</description><contents><choicetitle="ngIRCd daemon"id="choicengircd"tooltip="ngIRCd daemon, documentation and manual pages"description="Binaries, documentation and manual pages of the ngIRCd, the next generation IRC (Internet Relay Chat) daemon. This package will be installed into /opt/ngircd."starts_selected="true"starts_enabled="true"starts_hidden="false"><pkgrefid="de.barton.ngircd.daemon.pkg"/></choice><choicetitle="Start and stop script"id="choicelaunchscript"tooltip="LaunchDaemon start and stop script"description="Installs the ngIRCd start and stop script for the "launch daemon". If this is an update/upgrade, and ngIRCd is already running, it will be automatically restarted."starts_selected="true"starts_enabled="true"starts_hidden="false"><pkgrefid="de.barton.ngircd.launchscript.pkg"/></choice></contents><resourcesbg-scale="none"bg-align="bottomleft"><localelang="en"><resourcetype="background">/Users/alex/Develop/ngircd/alex.git/contrib/ngIRCd-Logo.gif</resource><resourcemime-type="text/rtf"kind="embedded"type="license"><![CDATA[{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf350
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. \
\
Please see below and read the file COPYING, README and AUTHORS for more information.\
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.\
\
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.\
\
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.\
\
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.\
\
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.\
\
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.\
\
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.\
\
The precise terms and conditions for copying, distribution and modification follow.\
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law:\
that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".\
\
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the\
Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.\
\
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.\
\
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.\
\
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1above, provided that you also meet all of these conditions:\
\
a) You must cause the modified files to carry prominent notices\
stating that you changed the files and the date of any change.\
\
b) You must cause any work that you distribute or publish, that in\
whole or in part contains or is derived from the Program or any\
part thereof, to be licensed as a whole at no charge to all third\
parties under the terms of this License.\
\
c) If the modified program normally reads commands interactively\
when run, you must cause it, when started running for such\
interactive use in the most ordinary way, to print or display an\
announcement including an appropriate copyright notice and a\
notice that there is no warranty (or else, saying that you provide\
a warranty) and that users may redistribute the program under\
these conditions, and telling the user how to view a copy of this\
License. (Exception: if the Program itself is interactive but\
does not normally print such an announcement, your work based on\
the Program is not required to print an announcement.)\
\page \
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.\
\
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.\
\
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.\
\
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:\
\
a) Accompany it with the complete corresponding machine-readable\
source code, which must be distributed under the terms of Sections\
1 and 2 above on a medium customarily used for software\
interchange; or,\
\
b) Accompany it with a written offer, valid for at least three\
years, to give any third party, for a charge no more than your\
cost of physically performing source distribution, a complete\
machine-readable copy of the corresponding source code, to be\
distributed under the terms of Sections 1 and 2 above on a medium\
customarily used for software interchange; or,\
\
c) Accompany it with the information you received as to the offer\
to distribute corresponding source code. (This alternative is\
allowed only for noncommercial distribution and only if you\
received the program in object code or executable form with such\
an offer, in accord with Subsection b above.)\
\
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.\
\
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not\
compelled to copy the source along with the object code.\
\
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.\
\
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.\
\
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.\
\
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.\
\
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.\
\
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.\
\
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.\
\page \
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.\
\
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.\
\
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.\
\
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.\
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.\
\
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.}]]></resource><resourcemime-type="text/rtf"kind="embedded"type="readme"><![CDATA[{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf350
\f0\fs26 \cf0 ngIRCd is a free and open source daemon for the Internet Relay Chat (IRC) protocol, developed under the GNU General Public License (GPL). It is written from scratch, is quite portable and is not based upon the original IRCd like many others.\
You will be guided through all steps necessary to install this software on Mac OS X.}]]></resource><resourcemime-type="text/rtf"kind="embedded"type="conclusion"><
