inspircd / inspircd

A modular C++ IRC server (ircd).

About

InspIRCd is a modular C++ Internet Relay Chat (IRC) server for UNIX-like and Windows systems.

Supported Platforms

InspIRCd is supported on the following platforms:

• Most recent BSD variants using the Clang 5+ or GCC 7+ compilers and the GNU toolchains (Make, etc).

• Most recent Linux distributions using the Clang 5+ or GCC 7+ compilers and the GNU toolchain.

• The most recent three major releases of macOS using the AppleClang 10, Clang 5+, or GCC 7+ (not LLVM-GCC) compilers and the GNU toolchain.

• Windows 10 build 17061 or newer using the MSVC 19.15+ (Visual Studio 15.8 2017) compiler and CMake 3.20 or newer.

Other platforms and toolchains may also work but are not officially supported by the InspIRCd team. Generally speaking if you are using a reasonably modern UNIX-like system you should be able to build InspIRCd on it. If you can not and you wish to submit a patch we are happy to accept it as long as it is not extremely large.

If you encounter any bugs then please file an issue.

Installation

Most InspIRCd users running a UNIX-like system build from source. A guide about how to do this is available on the InspIRCd docs site.

Building from source on Windows is generally not recommended but a guide is available if you wish to do this.

If you are running on Debian 12/13, RHEL 8/9, Ubuntu 22.04/24.04, or Windows 10+ binary packages are available from the downloads page.

Some distributions ship an InspIRCd package in their package managers. We generally do not recommend the use of such packages as in the past distributions have made broken modifications to InspIRCd and not kept their packages up to date with essential security updates.

License

InspIRCd is licensed under version 2 of the GNU General Public License.

External Links

• Website
• Documentation
• GitHub
• Social Media
• Support IRC channel — #inspircd on irc.chatspike.net
• Development IRC channel — #inspircd.dev on irc.chatspike.net
• InspIRCd test network — testnet.inspircd.org

inspircd's Issues

[2.0] Server Links With OpenSSL Repeatedly Split

This problem only affects server links done with OpenSSL exclusively or a mixture of OpenSSL and GnuTLS, not GnuTLS exclusively. If you have a network that meets the previously mentioned condition, servers will split daily (sometimes two or more at once), for seemingly no reason. The error given is:

<Mastodon.Hub.EU.AlphaChat.net> LINK Connection to Evolution.FR.EU.AlphaChat.net failed with error SSL Connection closed

Using the same servers with the same build of InspIRCd, but instead using only GnuTLS instead of OpenSSL for server links, the servers stay linked fine without any issues. Using OpenSSL for clients is also fine. Servers stay linked and clients do not get disconnected.

m_spanningtree forwards messages blindly regardless of burst status

hi,

inspircd's m_spanningtree forwards messages blindly regardless of burst status. in other words, if you send a PING to a new server, in response to a SERVER message being received (to determine if it is truly synced or not), that PING will be dropped by the new server as it hasn't received a burst yet.

see logs in #37 for details.

[2.0] Client cert shown on different numeric

Due to the 'has client certificate fingerprint' line reporting on a different numeric than the 'has an ssl connection' line some clients, mainly mIRC, fail to recognize that it's part of the /whois output and thus put it in the wrong window.

I was wondering if we could change this to run on the same numeric as the 'has an ssl connection' line without any problems.

Servers accept topics from the losing side at netmerge (FTOPIC has no chan TS)

Since we only send the topic timestamp in FTOPIC if someone recreates the channel during a netsplit and sets a topic that topic will override the original on the winning side because currently we only check if remote topic ts >= our topic ts before accepting an FTOPIC

ModuleManager fails with ambiguous error on systems without LWP SSL support

On systems without LWP SSL support, ModuleManager fails with the following error:

Could not retrieve https://raw.github.com/inspircd/inspircd-extras/master/modules.lst

I suspect that this error is caused by lack of SSL support. I also suspect that to fix this error, Crypt::SSLeay is required.

Not using SSL doesn't seem to be an option as GitHub appears to force SSL.

please add support for server-side MLOCK

hi,

atheme-5 and newer have support for server-side MLOCK synchronization. this is supported by unreal 3.2.10 (added in atheme-7) and charybdis already.

the way it works is, services sends a list of modeletters which may not be changed, then the ircd simply drops any mode changes for those letters.

this works on all sorts of modes, not just simple modes and lockable modes, for example, atheme-7.1 turned on ircd-side enforcement of SECURE using the serverside MLOCK mechanism.

the net benefit to server-side benefit is that the ircd blocks mode changes that would otherwise be bounced (providing an explanation of course), creating a more straightforward user experience.

[2.0] m_dnsbl Not Working with CGI:IRC

InspIRCd's m_dnsbl module does not work with connections originating from CGI:IRC blocks using m_cgiirc. If a user with a host in a DNSBL connects through a CGI:IRC applet, m_dnsbl will not take any action against them.

A semi-related issue is that if an E-line is added on the IP of a CGI:IRC block, connections originating from that block are exempt from all X-lines. For example, if the host 127.0.0.2 is Z-lined and a user attempts to connect to the server through a CGI:IRC applet under this condition, they will be able to connect as if no ban is placed on their IP.

I believe these both affect 1.2, as well (unsure of status with 2.1), though I'm not 100% sure.

[2.1] Invaild mode errors when OpenSSL module is unloaded

If the OpenSSL is unloaded globally, and then one server netsplits, the server WILL reconnect. However, after one second, it will netsplit again with Link Terminated: Invalid mode sequence passed to ModeParser::Process! as the error.

This can be solved by restarting the whole network.

I have only had this issue on 2.1b3. (But have only tested on 2.0 and 2.1b3)

extensible.h missing stdint.h include?

Hi,

I'm getting

An error occured when executing: g++ -o obj/bancache.o -pipe -fPIC -DPIC -pedantic -Woverloaded-virtual -Wshadow -Wformat=2 -Wmissing-format-attribute -Wall -O2 -g1 -Iinclude -c /home/kshade/build/x/inspircd/src/bancache.cpp
In file included from include/inspircd.h:64:0,
                 from /home/kshade/build/x/inspircd/src/bancache.cpp:16:
include/extensible.h:152:2: error: ‘intptr_t’ does not name a type
include/extensible.h:153:2: error: ‘intptr_t’ does not name a type

on Arch Linux with GCC 4.7 unless I add

#include <stdint.h>

to the top of the file.

Support WHOX

It would be nice if InspIRCd would support WHOX. It is an enchantment for the /who command.

WHOX is supported on many different IRCds and is a useful enchantment.
Basically the client can ask only for the informations it needs.

The benefits are:

• Possible traffic reducing, because not all fields might be requested and therefore sended.
• Possibility to add extra fields in extended who queries like the accountname.

For more information read:
http://hg.quakenet.org/snircd/file/37c9c7460603/doc/readme.who
Please note that all known IRCds that support whox add WHOX in the 005 nummeric. This is not mentioned in the documentation above.

Implementation Notes:
It is required that each module can add new flags and fields. This is especially required for m_services_account.

If I have the time I will try to implement this.

[2.1] m_ident: ident requesting does not work properly

I have useident="yes" but to no avail, it keeps saying "Could not find your ident".

[2.0] ssl not working with IPv6

I have successfully enabled ipv6 on all my servers and created a ipv6 only server and have it linked I can join it with out issue on all non ssl ports and interact but I can not join using the ssl port. This is the same for ipv6 servers.

Fails to build on Debian Hurd

Hi,

Please find below a patch to build inspircd on Debian GNU/Hurd platforms:

http://bugs.debian.org/669176

(sorry, saw it too late to merge it with issue 65)

[1.2/2.0/2.1] Feature: Do not "stack" snomask messages (or make it configurable)

I'd like to request a feature concerning how snomasks works when messages are repeated. When they are repeated you get outputs like this "(last message repeated X times)", this however is causing our current opered bot to get out of sync because it expects realtime information to act upon (a fast quitting/reconnecting user for example already triggers this).

My request is to have the ircd not "stack" the messages but just send it as events are happening to an opered bot and let it deal with it instead. It would be nice if this whole system could be turned on or off so it can be used with the chanlog module too (and this ability would already be enough actually).

m_callerid crashes on 2.0.5

Occasionally, m_callerid causes a crash of InspIRCd 2.0.5 on a 64-bit Linux machine. Occasionally, the message is passed on to other servers (of the same version) on the network, causing them to break down as well. After multiple occurrences, one server was compiled with debug information. Here is a backtrace:

Program terminated with signal 11, Segmentation fault.
#0  0x00000000004a9e6e in reference<ExtensionItem>::operator< (
    this=0x206e754a20756874, other=...) at include/base.h:140
140     inline bool operator<(const reference<T>& other) const { return value < other.value; }
(gdb) bt full
#0  0x00000000004a9e6e in reference<ExtensionItem>::operator< (
    this=0x206e754a20756874, other=...) at include/base.h:140
No locals.
#1  0x00000000004a9157 in std::less<reference<ExtensionItem> >::operator() (
    this=0x1290fd8, __x=..., __y=...)
    at /usr/include/c++/4.4/bits/stl_function.h:230
No locals.
#2  0x00000000004a9360 in std::_Rb_tree<reference<ExtensionItem>, std::pair<reference<ExtensionItem> const, void*>, std::_Select1st<std::pair<reference<ExtensionItem> const, void*> >, std::less<reference<ExtensionItem> >, std::allocator<std::pair<reference<ExtensionItem> const, void*> > >::_M_lower_bound (
    this=0x1290fd8, __x=0x206e754a20756854, __y=0x1290fe0, __k=...)
    at /usr/include/c++/4.4/bits/stl_tree.h:1002
No locals.
#3  0x00000000004a83bc in std::_Rb_tree<reference<ExtensionItem>, std::pair<reference<ExtensionItem> const, void*>, std::_Select1st<std::pair<reference<ExtensionItem> const, void*> >, std::less<reference<ExtensionItem> >, std::allocator<std::pair<reference<ExtensionItem> const, void*> > >::find (this=0x1290fd8, 
    __k=...) at /usr/include/c++/4.4/bits/stl_tree.h:1434
        __j = {_M_node = 0x7fff9c69e160}
#4  0x00000000004a7af9 in std::map<reference<ExtensionItem>, void*, std::less<reference<ExtensionItem> >, std::allocator<std::pair<reference<ExtensionItem> const, void*> > >::find (this=0x1290fd8, __x=...)
    at /usr/include/c++/4.4/bits/stl_map.h:674
No locals.
#5  0x00000000004a5799 in ExtensionItem::get_raw (this=0x850b88, 
    container=0x1290fd0) at /home/irc/inspircd/src/base.cpp:95
        i = {_M_node = 0xffaeb0}
#6  0x00007f5e07c58803 in CallerIDExtInfo::get (this=0x850b88, user=0x1290fd0, 
    create=false) at /home/irc/inspircd/src/modules/m_callerid.cpp:94
        dat = 0x7f5e07c5ae6d
#7  0x00007f5e07c588c8 in CallerIDExtInfo::free (this=0x850b88, item=0x12edf00)
    at /home/irc/inspircd/src/modules/m_callerid.cpp:110
        targ = 0x0
        it = {_M_node = 0x1074590}
        dat = 0x12edf00
#8  0x00000000004a5fcd in Extensible::cull (this=0x8f00d0)
    at /home/irc/inspircd/src/base.cpp:184
        i = {_M_node = 0x9fb730}
#9  0x00000000005533f1 in User::cull (this=0x8f00d0)
    at /home/irc/inspircd/src/users.cpp:555
No locals.
#10 0x00000000004ed50e in CullList::Apply (this=0x7fa240)
    at /home/irc/inspircd/src/cull_list.cpp:42
        c = 0x8f00d0
        i = 92
        working = {<std::_Vector_base<LocalUser*, std::allocator<LocalUser*> >> = {
            _M_impl = {<std::allocator<LocalUser*>> = {<__gnu_cxx::new_allocator<LocalUser*>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, 
              _M_end_of_storage = 0x0}}, <No data fields>}
        gone = {_M_t = {
            _M_impl = {<std::allocator<std::_Rb_tree_node<classbase*> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<classbase*> >> = {<No data fields>}, <No data fields>}, 
              _M_key_compare = {<std::binary_function<classbase*, classbase*, bool>> = {<No data fields>}, <No data fields>}, _M_header = {
                _M_color = std::_S_red, _M_parent = 0xce8b40, 
                _M_left = 0xcb75b0, _M_right = 0x13de640}, 
              _M_node_count = 93}}}
        queue = {<std::_Vector_base<classbase*, std::allocator<classbase*> >> = {
            _M_impl = {<std::allocator<classbase*>> = {<__gnu_cxx::new_allocator<classbase*>> = {<No data fields>}, <No data fields>}, _M_start = 0x14725c0, 
              _M_finish = 0x14728a0, 
              _M_end_of_storage = 0x1472a40}}, <No data fields>}
#11 0x0000000000506b6c in InspIRCd::Run (this=0x7ea220)
    at /home/irc/inspircd/src/inspircd.cpp:796
        ru = {ru_utime = {tv_sec = 1448, tv_usec = 838546}, ru_stime = {
            tv_sec = 286, tv_usec = 185885}, ru_maxrss = 28476, ru_ixrss = 0, 
          ru_idrss = 0, ru_isrss = 0, ru_minflt = 12845, ru_majflt = 1172, 
          ru_nswap = 0, ru_inblock = 255672, ru_oublock = 1219344, 
          ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 12157562, 
          ru_nivcsw = 464}
        OLDTIME = 1340243645
#12 0x0000000000506eb6 in main (argc=2, argv=0x7fff9c69e6b8)
    at /home/irc/inspircd/src/inspircd.cpp:841

I have been unable to reproduce the issue.

Fails to build with gcc-4.7

Hi,

Please find a patch to build inspircd with gcc-4.7:

From: Guillaume Delacour <[email protected]>
Subject: FTBFS with gcc-4.7, include unistd.h
Origin: http://gcc.gnu.org/gcc-4.7/porting_to.html

--- a/include/inspircd.h
+++ b/include/inspircd.h
@@ -43,6 +43,7 @@
 #include <cstring>
 #include <climits>
 #include <cstdio>
+#include <unistd.h>

 #include <sstream>
 #include <string>

copyright holdership clarification would be nice

hi,

code assigns copyright to "InspIRCd development team" and refers to a now-broken link.

two questions:

• is "InspIRCd development team" at present a legal entity capable of copyright holdership?
• who comprises "InspIRCd development team"?

example confs copied every 'make install'

Every time you do a make install, the example configs are copied into your run/conf directory. In that way it's cluttering your config directory and that is imho unnecessary. I'd like to hear improvement suggestions.

[2.0 + 2.1] remote restriction on /stats

Restricted /stats works only on local server.
If an user, for example, types /stats u server.mynet.tld the command will show uptime instead of "permission denied".

[1.1] Excessive CPU usage

A recent package upgrade for InspIRCd in Ubuntu 10.04 LTS causes it to use a lot of CPU with the default configuration. This behaviour did not occur in the previous version of the package. With the exception of the excessive CPU usage, the server works fine (accepts and processes connections as usual).

Relevant package: https://launchpad.net/ubuntu/+source/inspircd/1.1.22+dfsg-4squeeze1build0.10.04.1
Diff: http://launchpadlibrarian.net/102255194/inspircd_1.1.22%2Bdfsg-4_1.1.22%2Bdfsg-4squeeze1build0.10.04.1.diff.gz

I've been unable the determine the exact cause, other than that there seems to be some excessive polling going on. This most likely affects the upstream Debian package as well.

# inspircd --version

InspIRCd-1.1.22+Azeitao r0
# inspircd --debug --nofork --logfile /var/log/inspircd.log --config /etc/inspircd/inspircd.conf
Inspire Internet Relay Chat Server, compiled Apr 16 2012 at 19:39:24
(C) InspIRCd Development Team.

Developers:             Brain, FrostyCoolSlug, w00t, Om, Special, pippijn, peavey, Burlex
Others:                 See /INFO Output
Wed Apr 25 07:13:22 2012: WARNING: <options:softlimit> value is greater than 1024 or less than 0, set to 1024.
Wed Apr 25 07:13:22 2012: Filename: /etc/inspircd/inspircd.motd
Wed Apr 25 07:13:22 2012: Filename: /etc/inspircd/inspircd.rules
Wed Apr 25 07:13:22 2012: Reading connect classes...
Wed Apr 25 07:13:22 2012: Done reading configuration file.

Loading core commands.......................................................
Wed Apr 25 07:13:22 2012: New socket binding for 4 with listen: 127.0.0.1:6667
Wed Apr 25 07:13:22 2012: New file descriptor: 4 (1)

Wed Apr 25 07:13:22 2012: New socket binding for 5 without listen: :-1
Wed Apr 25 07:13:22 2012: New file descriptor: 5 (1)

A total of 0 modules have been loaded.
Wed Apr 25 07:13:22 2012: Total loaded modules: 0
Wed Apr 25 07:13:22 2012: Keeping pseudo-tty open as we are running in the foreground.

InspIRCd is now running!
Wed Apr 25 07:13:22 2012: Startup complete.

# strace -p 1319
Process 1319 attached - interrupt to quit
time(NULL)                              = 1335338010
poll([{fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=0, events=0}, {fd=0, events=0
}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, eve
nts=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0
, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, ...], 1024, 1000) = 1 ([...])
time(NULL)                              = 1335338010
poll([{fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=0, events=0}, {fd=0, events=0
}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, eve
nts=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0
, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, ...], 1024, 1000) = 1 ([...])
time(NULL)                              = 1335338010
poll([{fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=0, events=0}, {fd=0, events=0
}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, eve
nts=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0
, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, {fd=0, events=0}, ...], 1024, 1000) = 1 ([...])
time(NULL)                              = 1335338010
...

[all] WHOIS for non-existant nick produces wrong output

Doing a whois for a non-existant nick produces the following output:
WHOIS nick2
:inspircd.test 401 nick nick2 :No such nick/channel
:inspircd.test 318 nick * :End of /WHOIS list.

the correct output would be
WHOIS nick2
:inspircd.test 401 nick nick2 :No such nick/channel
:inspircd.test 318 nick nick2 :End of /WHOIS list.

Fix: cmd_whois.cpp:79 (1.2.9rc1)
The third line is missing an ! which results in the wrong output:

/* no such nick/channel */ user->WriteNumeric(401, "%s %s :No such nick/channel",user->nick.c_str(), !parameters[userindex].empty() ? parameters[userindex].c_str() : "*"); user->WriteNumeric(318, "%s %s :End of /WHOIS list.",user->nick.c_str(), parameters[userindex].empty() ? parameters[userindex].c_str() : "*");

fixed code:
/* no such nick/channel */ user->WriteNumeric(401, "%s %s :No such nick/channel",user->nick.c_str(), !parameters[userindex].empty() ? parameters[userindex].c_str() : "*"); user->WriteNumeric(318, "%s %s :End of /WHOIS list.",user->nick.c_str(), !parameters[userindex].empty() ? parameters[userindex].c_str() : "*");

[2.0] Desync Issues

InspIRCd 2.0 has a few desync issues. A good example is with channel mode "f." For example, say you have a network with 1 hub and 3 leaves. Two users are on separate leaves. A user on the hub will see a user getting kicked for surpassing the limits specified under the "f" channel mode, however, the user on a leaf that isn't the same leaf as the user being kicked will not see the user get kicked. Another example of this is with the "w" channel mode, where if a user is assigned a mode through this, such as voice, not all servers will see this mode assigned.

I've also noticed an issue with InspIRCd 2.0 and Atheme services on multiple IRC networks where if Atheme is linked to a hub server and a leaf is linked after Atheme is started, Atheme's InfoServ notices and ENFORCE, among other things, do not always work on the leaf that was linked after Atheme was started.

Additional short example config

I'd like to propose to have another example configuration for (semi-)experienced admins. The current example config is around 3000 lines. That's just an abnomination to work through more than once.

My proposal of a new "quick" example config, unifying these files:

• inspircd.conf without any explanations as most options are fairly self-documenting.
• modules.conf with one-line module descriptions. Any configuration options the module may have go undocumented
• opers.conf with a quick list of privs and all commands that are not provided by any module and (also undocumented) example type+oper blocks with all possible options (module-based ones not included, admins are supposed to remember those from the module section what they need)
• links.conf without any docs, just example block, autoconnect and uline block

All other files are module-based and can be handled on a case-by-case basis by the admin.

Just to make it clear, this is not supposed to replace the current example configuration, but instead an attempt to make a shorter, simpler one for small networks who don't need everything in its own file, and for admins who already know what they're doing (for the most part at least).

[2.1] m_opermodes.so incorrect documentation

In 2.1b3 (and HEAD), m_opermodes.so does not set the modes specified in <type:modes> on oper-up.

[1.2/2.0] MODE can be used to view modes on secret channels

When setting a channel secret MODE will still return the modes correctly from outside the channel. I think this should be changed to return 'no such channel' as other commands, such as NAMES

>> MODE #Opers
<< #opers +Pinst
<< #opers 1021053379
>> NAMES #Opers
<< #opers :No such nick/channel

The RFC does state that this is the expected behavior, but changing it likely wont break any clients and it would prevent the possibility, however small, of brute forcing a secret channel name.

[2.0] Segfault caused by decoding error in certificate used by m_ssl_gnutls

InspIRCd 2.0 may encounter a segmentation fault in certain cases when it encounters a base64 decoding error in a certificate file while trying to load m_ssl_gnutls.

Following is part of a log from a test server running in debug mode:

Thu May 31 18:18:21 2012: C[121AAAAAA] I :Chocolate_Caramel LOADMODULE m_ssl_gnutls.so
Thu May 31 18:18:21 2012: OPERLOG: [Chocolate_Caramel![e-mail]] LOADMODULE m_ssl_gnutls.so
Thu May 31 18:18:21 2012: classbase::+ @0x721d70
Thu May 31 18:18:21 2012: classbase::+ @0x719f70
Thu May 31 18:18:21 2012: classbase::+ @0x719fc0
Thu May 31 18:18:21 2012: classbase::+ @0x719fc8
Thu May 31 18:18:21 2012: classbase::+ @0x71a030
Thu May 31 18:18:21 2012: classbase::+ @0x71a058
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Enabling SSL for port [::]:6560
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Enabling SSL for port [::]:6561
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Enabling SSL for port [::]:6562
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Enabling SSL for port [::]:6563
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Enabling SSL for port [::]:6564
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Enabling SSL for port [::]:6565
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Failed to set X.509 trust file 'conf/ca.pem': Error while reading file.
Thu May 31 18:18:21 2012: m_ssl_gnutls.so: Failed to set X.509 CRL file 'conf/crl.pem': Error while reading file.
Thu May 31 18:18:21 2012: classbase::+ @0x7fffffffd810
Thu May 31 18:18:21 2012: classbase::~ @0x7fffffffd810
Thu May 31 18:18:21 2012: S[20] O :121 METADATA * modules :-m_ssl_gnutls.so
Thu May 31 18:18:21 2012: Module m_ssl_gnutls.so unloaded
Thu May 31 18:18:21 2012: Unable to load m_ssl_gnutls.so: Unable to load GnuTLS server certificate (conf/cert.pem): Base64 decoding error.
Thu May 31 18:18:21 2012: C[121AAAAAA] O :hurricane.blacklnet.org 974 Chocolate_Caramel m_ssl_gnutls.so :Unable to load m_ssl_gnutls.so: Unable to load GnuTLS server certificate (conf/cert.pem): Base64 decoding error.
Thu May 31 18:18:21 2012: Deleting 15ModuleSSLGnuTLS @0x719f70
Thu May 31 18:18:21 2012: classbase::-15ModuleSSLGnuTLS @0x719f70

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe16cd199 in ?? () from /usr/lib/libgcrypt.so.11
(gdb) bt
#0  0x00007fffe16cd199 in ?? () from /usr/lib/libgcrypt.so.11
#1  0x00007fffe191f1f6 in ?? () from /usr/lib/libgnutls.so.26
#2  0x00007fffe192872e in gnutls_dh_params_deinit () from /usr/lib/libgnutls.so.26
#3  0x00007fffe1b9efa2 in ~ModuleSSLGnuTLS () from /home/blackl/opt/inspircd-hurricane/modules/m_ssl_gnutls.so
#4  0x00000000004589cf in CullList::Apply ()
#5  0x0000000000466a72 in InspIRCd::Run ()
#6  0x0000000000469cc2 in main ()
(gdb) 

If there's any other information I need to provide or any other way I can help, please let me know ^^

Fix ZLINE not checking ELINE

When a ZLINE is created, if it partially matches an ELINE (ip), it should be converted to a GLINE for _@ip.
When a GLINE is created, if it _partially* matches an ELINE (ident or ip), it should no convert to a ZLINE.

This would fix ZLINEs ignoring ELINEs in theory.

Move modules which duplicate behaviour into inspircd-extra on the 2.1 branch

I propose that the following modules which duplicate behaviour provided by other modules are moved into inspircd-extras for 2.1:

• m_chanprotect (replaced by m_customprefix)
• m_halfop (replaced by m_customprefix)

Moving these modules into inspircd-extra would simplify the module config without causing problems for people who need these modules for linking compatibility with servers running an older version of InspIRCd or services packages which do not check for m_customprefix.

[2.0] m_chanfilter does not allow removal of unicode characters

Hi,
I added a degree sign a while back to block some people's scripts they had but now that it's all over I cannot seem to remove the characters.

when I do a list of the banned words i have the following:
»» #Computers *°F* NorthStar.Azuru.net 1337087664
»» #Computers *°* NorthStar.Azuru.net 1337087664

when I try and do /mode #Computers -g *°F* it replies with:
»» #Computers :No such spamfilter word is set

The error seems simple enough and I can remove all other messages just fine.

[2.1] m_ssl_gnutls.cpp compile error

This is with GnuTLS 2.4.2 on Fedora 10. InspIRCd 2.0.X compiles fine because it seems it did not get this change.

An error occured when executing: g++ -o modules/m_ssl_gnutls.so -pipe -fPIC -DPIC -Iinclude -pedantic -Woverloaded-virtual -Wshadow -Wformat=2 -Wmissing-format-attribute -Wall -Wextra -Wno-unused-parameter -Winit-self -Wfloat-equal -Wcast-qual -Wcast-align -Wpacked -Wredundant-decls -Wno-variadic-macros -O2 -g1 -DVERSION_GNUTLS=2.4.2 -DMODNAME=m_ssl_gnutls.so -fPIC -shared -rdynamic /home/ircd/networks/testnet/inspircd/insp21-8d53b56/src/modules/m_ssl_gnutls.cpp -lgnutls -lgcrypt
/home/ircd/networks/testnet/inspircd/insp21-8d53b56/src/modules/m_ssl_gnutls.cpp: In constructor ‘GnuTLS::DH_info::DH_info()’:
/home/ircd/networks/testnet/inspircd/insp21-8d53b56/src/modules/m_ssl_gnutls.cpp:48: error: ‘GNUTLS_PK_DH’ was not declared in this scope
/home/ircd/networks/testnet/inspircd/insp21-8d53b56/src/modules/m_ssl_gnutls.cpp:48: error: ‘GNUTLS_SEC_PARAM_NORMAL’ was not declared in this scope
/home/ircd/networks/testnet/inspircd/insp21-8d53b56/src/modules/m_ssl_gnutls.cpp:48: error: ‘gnutls_sec_param_to_pk_bits’ was not declared in this scope
make[1]: *** [modules/m_ssl_gnutls.so] Error 1
make: *** [target] Error 2

[Proposal] Development changes

After some talk in #InspIRCd the following changes have been proposed:

1. Git stable branches will be renamed to follow the naming format release/X.Y using git branch -m old_branch new_branch:
   • release/1.0
   • release/1.1
   • release/1.2
   • release/2.0
2. The current 2.1 branch will be frozen and a new master branch will be forked from release/2.0
   • The changes from the current 2.1 branch will be migrated to the new master branch.
   • When the changes have been migrated to the master branch the current 2.1 branch will be purged using git push origin --delete insp21.
3. The master branch will become the primary target of patches with older versions receiving bugfix-only backports unless the patch is specific to a specific branch in which case the patch should be filed for the most recent version it applies to first.
4. When the master branch is considered feature complete, a new release/X.Y branch will be forked from it.
5. Release branches are supported until the release after next. Long term support releases could be introduced for distributions which update slowly (i'm looking at you, Debian) to use.

InspIRCd 2.1 broken on Windows

As reported by Merbo, InspIRCd 2.1 is broken on Windows. I have tried to fix it but it is unfortunately beyond my ability to do so.

From what i can gather, the following commits (there may be others I have missed) need to be forwarded to 2.1:

• b56565e
• e8f97ac
• f5409f0
• e46e500
• 699a8b2
• b279f30
• 2a76f49
• d6067d1

This seems to be part of a wide gap where patches have only been applied to 2.0 and not 2.1 which will probably need to be closed before 2.1 is released.

[1.2] minor memory leak in modules

A memory leak occurs when unloading one of the following modules because the (specialized) xlinefactory created in the constructor is never deleted.
Fix: delete the instance in the destructor after the UnregisterFactory call.

Affected modules:

• m_svshold
• m_rline
• m_shun
• m_cban

[security] does not close stdin or stderr on startup, consumes 100% cpu

From Debian bug #668253. The reference to privilege escalation is to CVE-2012-1836 (this problem should probably also get a CVE id):

Version: 1.1.22+dfsg-4
Severity: important
Tags: security

I noticed that my inspircd would run at 100% CPU usage after being
restarted. Well actually this only started after I logged out. A quick
strace shows that inspircd calls poll in a loop and the result is always
fd=0. lsof then shows that fd=0 is connected to the terminal I used to
restart inspircd. When I logged out, it was closed and poll would always
return that fd. The problem is worse though. This can be used to
escalate privileges (from irc to root) when combined with an arbitrary
code execution flaw (such as the one fixed in DSA-2448-1).

Interestingly this problem does not exist according to the
documentation (include/inspircd.h):

| /** Daemonize the ircd and close standard input/output streams
| * @return True if the program daemonized succesfully
| */
| bool DaemonSeed();

However looking at the definition (src/inspircd.cpp) clearly shows that
the closing of the streams does not happen.

Fails to build on Debian GNU/kFreeBSD

Hi,

Please find below a patch to build inspircd on Debian kfreebsd-{i386,amd64} platforms:

http://bugs.debian.org/668253

[2.0] m_hideoper Altering /WHO Output Negatively

It's been reported to me that the "H" user mode causes /WHO to have an odd output with clients that have that mode applied:

immortal Statistics Stats.Bots.AlphaChat.net *.AlphaChat.net Stats H

Without the "H" mode applied, the output is proper:

immortal Statistics Stats.Bots.AlphaChat.net .AlphaChat.net Stats H :0 Stats Monitoring Bot

This does not affect opered clients who do /WHO, only regular clients.

EDIT: While experimenting with this a bit more on a test server, I noticed that if the client with "H" applied has voice, half-op, or channel operator (including "a" or "q"), the /WHO line for them is normal.

metadata isn't timestamped

while working on the mlock patch, i noticed metadata isn't timestamped. it probably should be...

LIST with empty parameter produces incomplete reply

Emacs ERC IRC client sends LIST with empty parameters -- not nice but
to my understanding ok according to the standard. For some reasons
this leads to inspircd replying with an incomplete channel list:

On the server in the following example there are two channels in
existence (#foo and #intevation), here is the on wire communication
log for list with empty parameters vs. list without parameter:

Milliways >> LIST :
Milliways << :chat.example.com 321 wilde Channel :Users Name
Milliways << :chat.example.com 322 wilde #foo 1 :[+int]
Milliways << :chat.example.com 323 wilde :End of channel list.

Milliways >> LIST
Milliways << :chat.example.com 321 wilde Channel :Users Name
Milliways << :chat.example.com 322 wilde #intevation 5 :[+nt] The forbidden network -- REALLY NEW -- Now with extra evil!
Milliways << :chat.example.com 322 wilde #foo 1 :[+int]
Milliways << :chat.example.com 323 wilde :End of channel list.

This was tested with v1.2.9.

add command: /geiop <nickname|hostname> and /stats G

it should stick in a meta field of whois
then you would either see it in /whois or in /who with flag
oper only
make m_geiop.so not an extra, make it compile normal
/stats G show how many people come from which country

Add a dependancy-free SSL module

A few months ago there was some talk in #InspIRCd about adding a SSL module which does not depend on an external SSL library so that users who do not have the access/skill to install OpenSSL/GnuTLS can benefit from secure communications.

It was proposed that this would be done via bundling the PolarSSL library. This library is apparently fairly well segmented so in theory we could remove the unneeded parts and bundle the rest with the SSL module. It is also licensed under the GPLv2 so there should not be any licensing issues relating to it.

[insp20] /stats P lists opers with +H

/stats P output lists opers with +H
*** Yuki ([email protected]) Idle: 410 secs
*** Yuki [email protected]
*** ircname : YukiBot 0.1
*** modes : +BHIorw

+H provided by m_hideoper. Probably would need another hook.

[2.0] InspIRCd should not unload all modules if it cannot locate a remote include on rehash

I am tired of seeing this: http://pastie.org/3740805 because I rehash and something in my DNS changed (dynamic DNS) and no longer resolves, thus causing inspircd to unload ALL core modules thinking that part of the config is now gone. Instead I think it should abort the rehash and maybe allow some kind of conformation override.

I also believe that when a DNS hostname is placed in the link:ipaddr block that the hostname be resolved at every rehash instead of being cached, it makes Dynamic DNS very annoying to work with when your old ip is cached.

[2.1] m_filter fails to read <keyword> tags

What it says on the tin.

reserved identifier violation

I would like to point out that identifiers like "__BASE_H__" and "__USERS_H__" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

The 45+ modules and SSL linking bug

The issue: when loading more then 45 modules, linking between servers while using SSL is not going to happen. This bug is originally reported on #inspircd by uTosTan and I have tested it in several cases (different settings, modules and platforms).

Note: there are some people who claims this should work with 2.0.2, but they haven't proven this (yet).

The test:
Compiled with make debug and configured two (echoes & sysyphus) ircd's (cloned from github) with this config: https://github.com/DjSlash/ircdconfigs/blob/master/long.conf - This time with openssl, but we tested a while ago with gnutls too, same issue. Now we are rebuilding bug reports.

Current platform for this test: Debian wheezy (testing) with openssl 1.0.0h and 1.0.0e

Number of modules being loaded:

$ grep -c '^<module' long.conf
46

Log from echoes:

Sun Mar 25 20:44:20 2012: LINK: AUTOCONNECT: Auto-connecting server sysyphus.selkof.net
Sun Mar 25 20:44:20 2012: classbase::+ @0x83321d0
Sun Mar 25 20:44:20 2012: New file descriptor: 0
Sun Mar 25 20:44:20 2012: BufferedSocket::DoConnect success
Sun Mar 25 20:44:20 2012: LINK: Connection to sysyphus.selkof.net[89.188.20.116] started.
Sun Mar 25 20:44:25 2012: Error on FD 0 - 'Connection closed'
Sun Mar 25 20:44:25 2012: LINK: Connection to sysyphus.selkof.net failed with error: Connection closed
Sun Mar 25 20:44:30 2012: Remove file descriptor: 0
Sun Mar 25 20:44:30 2012: LINK: Connection to 'sysyphus.selkof.net' failed.
Sun Mar 25 20:44:30 2012: LINK: Connection to 'sysyphus.selkof.net' was established for 10s
Sun Mar 25 20:44:31 2012: Deleting 10TreeSocket @0x83321d0
Sun Mar 25 20:44:31 2012: classbase::-10TreeSocket @0x83321d0
Sun Mar 25 20:44:31 2012: classbase::~ @0x83321d0

Log from sysyphus:

Sun Mar 25 20:44:20 2012: HandleEvent for Listensocket 89.188.20.116:6664 nfd=1
Sun Mar 25 20:44:20 2012: classbase::+ @0xafa2e0
Sun Mar 25 20:44:20 2012: New file descriptor: 1
Sun Mar 25 20:44:20 2012: Error on FD 1 - 'Write Error'
Sun Mar 25 20:44:20 2012: LINK: Connection to inbound from 82.73.157.77 failed with error: Write Error
Sun Mar 25 20:44:25 2012: DoWrite on errored or closed socket
Sun Mar 25 20:44:25 2012: Remove file descriptor: 1
Sun Mar 25 20:44:25 2012: LINK: Connection to 'inbound from 82.73.157.77' failed.
Sun Mar 25 20:44:25 2012: LINK: Connection to 'inbound from 82.73.157.77' was established for 5s
Sun Mar 25 20:44:26 2012: Deleting 10TreeSocket @0xafa2e0
Sun Mar 25 20:44:26 2012: classbase::-10TreeSocket @0xafa2e0
Sun Mar 25 20:44:26 2012: classbase::~ @0xafa2e0

Version not bumped in insp20 branch version.sh script

The version.sh script [1] defines previous version (2.0.5), but 2.0.6 version has been released according to [2].

The distribution file for 2.0.6 [3] ships with wrong version.sh.

Thanks.

[1] https://github.com/inspircd/inspircd/blob/insp20/src/version.sh
[2] http://inspircd.github.com/2012/04/09/inspircd-v206rc1-released.html
[3] https://github.com/downloads/inspircd/inspircd/InspIRCd-2.0.6rc1.tar.bz2

[ALL] IPv6 DNS Resolution Bug

With InspIRCd 2.0, if you connect to a server using IPv6 with a host that has an A and AAAA record, InspIRCd sees it as a mismatch and uses your IP instead.

I believe 1.2 is affected, as well. I'm not sure about 2.1.

non-SSL connect block restricts new connections even though it is placed after the fitting connect block with SSL

Apparently, a new SSL connection first connects as a non-SSL connection and begins applying connect blocks. If this fails, the user may get disconnected, even though a fitting connect block exists!

For example:

<connect (...) globalmax="20" requiressl="on">
<connect (...) globalmax="1" requiressl="off">

with otherwise identical settings in the blocks will limit the amount of SSL users to only one globally! The users get killed before the correct block, the one with SSL enabled, even gets applied.

Also, if an SSL user is connected in this example, it appears that non-SSL user cannot connect from that IP anymore. This seems counter-intuitive and also not very practical for this usage scenario.

It seems like the actual connection block used is a hybrid: whether or not to accept a connection is taken from the first matching non-SSL block, the rest comes from the correct block; the first one with SSL.

Support IRCv3 (extras)

InspIRCd should (fully) support the IRCv3 protocol, notably:

• account-notify
• away-notify
• extended-join

These are extra extensions, but would be very useful.

Specs for this (and all of the v3 protocol) can be found at: http://ircv3.atheme.org/

Process escape sequences in MOTD and rules

I propose that InspIRCd is extended to process escape sequences in the MOTD and rule files. This would allow users to use IRC control characters such as bold, underline and italic in these files without having to insert the raw characters which depending on your editor of choice may be hard.