charybdis-ircd / charybdis Goto Github PK

The current makefiles install a example.conf file, with no indication on how it should be installed. This file is really a good sample ircd.conf file.

Since we would like to ship a working config for the Debian package, it would better to install the ircd.conf directly. This should not affect existing installs because make install actually checks if the config file exists.

So please rename doc/example.conf to doc/ircd.conf, and apply this simple patch to the makefile:

--- a/doc/Makefile.in
+++ b/doc/Makefile.in
@@ -32,7 +32,7 @@
 mandir          = @mandir@/man8
 MANPAGES        = ircd.8

-CONFS      = example.conf reference.conf
+CONFS      = ircd.conf reference.conf

 SSL_LIBS   = @SSL_LIBS@
 SSL_INCLUDES   = @SSL_INCLUDES@

This was originally reported as http://jira.atheme.org/browse/CHARY-4 but lost.

When using RSA keys, dhparam size should match key size.

xn--y3haa.klined.me

Should become
☎☎☎.klined.me

Thanks!

the charybdis build depends on -rpath, which is considered bad practice in debian (see this post for more information). It would nice if we could turn that off in a configure flag. For now, we have this patch in the Debian package:

--- charybdis-3.3.0.orig/configure.ac
+++ charybdis-3.3.0/configure.ac
@@ -1013,17 +1013,6 @@ if test "$shared_modules" = yes; then
    fi
 fi

-# rpath, for finding libratbox.so at run time
-hold_ldflags=$LDFLAGS
-AC_MSG_CHECKING(for the ld -rpath flag)
-LDFLAGS="${LDFLAGS} -Wl,-rpath=${libdir}"
-AC_LINK_IFELSE(AC_LANG_PROGRAM([],[int i;]), found=yes, found=no)
-LDFLAGS=$hold_ldflags
-AC_MSG_RESULT($found)
-if test "$found" = yes; then
-   LDFLAGS="${LDFLAGS} -Wl,-rpath=\${libdir}"
-fi
-
 # This must be down here, or it will mess up checks like the ones
 # for -Wl,-export-dynamic
 # -- jilles

This was originally reported as http://jira.atheme.org/browse/CHARY-8 but then lost.

Just a quick note :)

The host cloaking isn't that great, at least for short strings. I can't attach code here, but some code and findings are here: http://pastie.org/4743103

This problem was observed in ircd-seven on FreeNode but it was recommended to bring it here.

If you (as a user/channel owner, not IRC oper) have a channel forward set up from some channel to another, via a +f in combination with a +i or widely-applying +b or whatever, then in most clients (by now anyway) you are forwarded without a problem. However if you happen to already be in the target channel, you are presented with an often-hostile message corresponding to the +i or +b or whatever mechanism you used to block access to the original channel.

For people who are not really familiar with IRC (and in fact for some who are), this behavior is pretty scary/off-putting. It would be nicer perhaps if the server always responded with the 470 "ERR_LINKCHANNEL" code in this case - or at the least, there should be a way to enable this behavior.

The web page linked to in the description of the GitHub repository does not exist any more. It should point to:

http://atheme.org/projects/charybdis.html

Rather than:

http://atheme.org/projects/charybdis

I've got this idea from the ChatIRCd fork:
https://bitbucket.org/chatlounge/chatircd

This would, for example, solve a problem that some channels on freenode and other networks have: They need a way to ban unidentified webchat users. I have been asked multiple times how to do it, and all I could ever give them was the following workaround:

/mode #channel +iII $~x:*gateway/web* $a

This fails when there is more than one of such masks to be exempted, and it might also cause other problems, as it somehow breaks +i and +I for the channel. With $u, however, they could simply use this:

/mode #channel +b $u:*!*@gateway/web* 

And if they need to ban unidentified users from badprovider.example.org, they could simply add:

/mode #channel +b $u:*!*@*.badprovider.example.org

...and it would still work, and the channel could be set +i whenever needed, and invite exempts would also still work as intended. $u is the missing extban that should be added to Charybdis to make the syntax complete. :)

I've found at least 2 oversights in the match_cidr function found in match.c:

In case of failure, rb_inet_pton returns 1, which is ignored, and most importantly, it doesn't modify the passed array, so if cidrlen is parsed appropriately, we would be comparing the user's IP address with uninitialized stack data.

Another issue is that no effort is made to impose any bounds on cidrlen. We are basically feeding a user-input number to memcmp. Only thanks to its implementation details it doesn't coredump the ircd. But we still get to peek into some bits of the stack.

I've managed to replicate both behaviors, it looks like this:

 * foo sets mode +b *!*@whatever/1
<bar> moo
 * foo sets mode -b *!*@whatever/1
 * foo sets mode +b *!*@whatever/1
<bar> moo
 * Cannot send to channel
 * foo sets mode -b *!*@whatever/1

And:

 * foo sets mode +b *!*@127.0.0.2/33
<bar> moo
 * Cannot send to channel
 * foo sets mode -b *!*@127.0.0.2/33
 * foo sets mode +b *!*@127.0.0.2/33
<bar> moo
 * foo sets mode -b *!*@127.0.0.2/33

The amount of data that is leaked seems laughable, but I assure you, with some effort it is possible to leak a whole byte of uninitialized stack data, and possibly even at different locations.

Getting this error on ./configure, I've never seen this before, and I'm not sure what to do. The machine is running latest Debian, same configuration as any other machine we have added to our network, so I'm not sure what might have changed to cause this on this machine in comparison with any other machine.

$ ./configure
configure: error: working directory cannot be determined

Currently, m_join.c hardcodes the default cmodes on an initial channel creation to +nt. Could this be configurable? I'm thinking something like this to do an override of the server default:

channel {
default_cmodes = "+sn";
}

Thank you.

configured like this

./configure --with-custom-branding=coolman --enable-warnings --enable-iodebug --prefix=/path/to/my/ircd

here's a backtrace

#0  0xb7d332d4 in strnlen () from /lib/i686/cmov/libc.so.6
#1  0xb7fb8814 in rb_strnlen (s=0x6 <Address 0x6 out of bounds>, count=4294967295) at tools.c:201
#2  0xb7fb830f in rb_vsnprintf (buf=0xb7c09e13 "coolman-ircd-3.5.0-dev(20140427-bf77c3a, testing.gangnet.ru). eHIKMpZ6 :", size=480, fmt=0xb6affb7c "s TS%dow %s", args=0xbfffee40 "\304\067#\b") at snprintf.c:454
#3  0xb7fb70b4 in rb_linebuf_putmsg (bufhead=0xbfffedf0, format=0xb6affb6b "%s(%s, %s). %s :%s TS%dow %s", va_args=0xbfffee0c, prefixfmt=0x8094d30 ":%s %03d %s ") at linebuf.c:534
#4  0x08084963 in sendto_one_numeric (target_p=0xb75b6e4c, numeric=351, pattern=0xb6affb6b "%s(%s, %s). %s :%s TS%dow %s") at send.c:384
#5  0xb6aff8aa in m_version (client_p=0xb75b6e4c, source_p=0xb75b6e4c, parc=1, parv=0x8228560) at m_version.c:77
#6  0x08070565 in handle_command (mptr=0xb6b00d00, client_p=0xb75b6e4c, from=0xb75b6e4c, i=1, hpara=0x8228560) at parse.c:371
#7  0x0806ffa2 in parse (client_p=0xb75b6e4c, pbuffer=0x8224540 "version", bufend=0x8224547 "") at parse.c:272
#8  0x0806fbab in client_dopacket (client_p=0xb75b6e4c, buffer=0x8224540 "version", length=7) at packet.c:369
#9  0x0806f48d in parse_client_queued (client_p=0xb75b6e4c) at packet.c:146
#10 0x0806f94d in read_packet (F=0xb7c3b50c, data=0xb75b6e4c) at packet.c:297
#11 0xb7fb9b3d in rb_select_epoll (delay=-1) at epoll.c:199
#12 0xb7fb1950 in rb_select (timeout=4294967295) at commio.c:2105
#13 0xb7fb64d4 in rb_lib_loop (delay=0) at ratbox_lib.c:229
#14 0x080662b8 in main (argc=0, argv=0xbffff1f8) at ircd.c:767

can anybody reproduce this?

Hi guys,
Recently, our group are trying to find ssl security problems by static anlysis. Now we have find some problems in charybdis and report this bugs to the launchpad, but we haven't receive any responses.
Could you please take a look at this bug:
https://bugs.launchpad.net/ubuntu/+source/charybdis/+bug/1380031
Thanks,
Rainkin

Viewing the ban/quiet list is not modehacking. Everyone can view it regardless of +p.

Hi,

before I go chasing around in circles, is there anything in charybdis that would prevent a wildcard SSL cert (e.g. *.foo.org) from being able to provide IRC to irc.foo.org over SSL? I am unsure if I am fighting a chaining issue or not. :)

Thank you.

Could you make the cipher suite used configurable? At the moment it uses reasonably secure defaults but in case you need to drop something in the future, or prefer to use something else, it would be nice to be able to specify your own. Also, allow configuring which SSL/TLS versions are supported.

I setup a test charybdis for #12 and i discovered i can't run charybdis without -foreground, because it crashes:

anarcat@marcos:core$ sudo -u charybdis strace -ff -e execve /usr/bin/charybdis-ircd
execve("/usr/bin/charybdis-ircd", ["/usr/bin/charybdis-ircd"], [/* 17 vars */]) = 0
Process 32595 attached
  notice: starting charybdis-3.5.0-dev ...
  notice: libratbox version: 20081213_1-26296 - GNUTLS: compiled (3.3.8), library(3.3.7)
[pid 32595] --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=32595, si_uid=129} ---
[pid 32594] +++ exited with 1 +++
+++ killed by SIGABRT (core dumped) +++

Here's the core dump backtrace:

(gdb) bt
#0  0x00007fa408e38077 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fa408e39458 in __GI_abort () at abort.c:89
#2  0x00007fa408bc0ceb in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
#3  0x00007fa407e1479d in nettle_mpz_random_size () from /usr/lib/x86_64-linux-gnu/libhogweed.so.2
#4  0x00007fa407e14814 in nettle_mpz_random () from /usr/lib/x86_64-linux-gnu/libhogweed.so.2
#5  0x00007fa407e16c39 in _nettle_rsa_blind () from /usr/lib/x86_64-linux-gnu/libhogweed.so.2
#6  0x00007fa407e15cb9 in nettle_rsa_pkcs1_sign_tr () from /usr/lib/x86_64-linux-gnu/libhogweed.so.2
#7  0x00007fa408bc34c3 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
#8  0x00007fa408b35782 in gnutls_privkey_sign_data () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
#9  0x00007fa408b27ebd in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
#10 0x00007fa408b32466 in gnutls_certificate_set_x509_key_mem2 () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
#11 0x00007fa4095f6550 in rb_setup_ssl_server () from /usr/lib/charybdis/libratbox.so
#12 0x000000000042b0ca in read_conf_files ()
#13 0x000000000040bb7a in main ()
(gdb)

BANDB_DBPATH cant be set externally because it is overwritten in bandbi.c

http://ircv3.net/specs/core/monitor-3.2.html
For this specification, ‘target’ MUST be a valid nick as determined by the IRC daemon.

ircd's from the same family as charybdis all seem to send a hostmask instead (checked freenode, esper, and ponychat) for RPL_MONONLINE which, by the letter of the spec, is wrong

Sample log from freenode:

::watcher >> NICK monitor-0
::watcher >> USER monitor * * {Monitor tests}
::watcher << :hobana.freenode.net 001 monitor-0 {Welcome to the freenode Internet Relay Chat Network monitor-0}
::watcher >> MONITOR + monitor-1
::watcher << :hobana.freenode.net 731 monitor-0 monitor-1
::joiner >> NICK monitor-1
::joiner >> USER monitor * * {Monitor tests}
::joiner << :card.freenode.net 001 monitor-1 {Welcome to the freenode Internet Relay Chat Network monitor-1}
::watcher << :hobana.freenode.net 730 * [email protected]
::joiner >> QUIT
::joiner << :[email protected] QUIT {Client Quit}
::joiner << ERROR {Closing Link: ppp118-209-252-10.lns20.mel8.internode.on.net (Client Quit)}
::watcher << :hobana.freenode.net 731 * monitor-1

ref ircv3/ircv3-specifications#103

basically we just need a numeric and then the ability to distribute the announcements, its pretty easy to do.

According to the copyright file, src/reslib.c is licensed under 4-clause 
BSD, while the rest of the code is under GPLv2 (or later). These two 
licenses are incompatible.

Indeed, this license (4 clause BSD) is incompatible with the GPL: http://www.gnu.org/licenses/license-list.html#OriginalBSD

This has been first reported in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684191

Include support for -fPIE in CFLAGS, except for modules and extensions. Drop hardcoded -O0. Include -D_FORTIFY_SOURCE=2, -fstack-protector

For LDFLAGS one should test and include "-Wl,-z -Wl,relro -Wl,-z -Wl,now -pie"

Servers fail to connect to a server configured in the following manner:

connect "herp.derp.network" {
host = "::1";
/* other options */
...
};

But succeed in connecting to servers configured in this manner instead:

connect "herp.derp.network" {
host = "0::1"; /* 0::1 instead of ::1 /
/ other options */
...
};

This distinction is undocumented and it is difficult to isolate it as the source of the issues it causes.

Please either document it or make the two behave the same way (which will, I believe, affect all ipv6 addresses that start with 0)

This would allow people to connect from the web browser without any plugins like Java. There are C libraries for this already, but should a re-implementation be needed the protocol is pretty simple.

I remember filing this in JIRA a while back, but it seems this was lost, so here we go again. Charybdis 3.3.0-7, Debian package (but I am pretty sure this is reproducable outside of Debian) on squeeze (so gnutls 2.6, i believe).

When linking against a server compiled against OpenSSL: no problem.

Linking against a server compiled against GnuTLS: kaboom.

17:40:44 [IMC] !one.example.com *** Notice -- ssld error for two.example.com: Read error: Input/output error

bt full

genesect bin > ls
bandb.old  bantool  bantool.old  convertilines  convertilines.old  convertklines  convertklines.old  genssl  genssl.old  ircd  ircd.old  mkpasswd  mkpasswd.old  ssld  ssld.old  viconf  viconf.old  vimotd

Missing file: bandb

kiril@vs1146:/charybdis$ uname -a
Linux vs1146.tux.bg 2.6.32-26-pve #1 SMP Mon Oct 14 08:22:20 CEST 2013 i686 i686 i386 GNU/Linux
kiril@vs1146:/charybdis$ cat /etc/redhat-release
CentOS release 6.4 (Final)
kiril@vs1146:~/charybdis$

1. Configure

config.status: executing libtool commands
/bin/rm: cannot remove `libtoolT': No such file or directory

build ==> src
make[1]: Entering directory /home/kiril/charybdis/src' gcc -I../include -I../libratbox/include -DIRCD_PREFIX=\"/home/kiril/ircd\" -O0 -Wall -std=gnu99 -g -g -O2 -c ircd.c gcc -O0 -Wall -std=gnu99 -g -g -O2 -Wl,-export-dynamic -Wl,-rpath=/home/kiril/ircd/lib -o ircd bandbi.o blacklist.o cache.o capability.o channel.o chmode.o class.o client.o extban.o getopt.o hash.o hook.o hostmask.o ipv4_from_ipv6.o irc_dictionary.o ircd.o ircd_signal.o listener.o logger.o match.o modules.o monitor.o newconf.o operhash.o packet.o parse.o privilege.o ratelimit.o res.o reslib.o reject.o restart.o s_auth.o s_conf.o s_newconf.o s_serv.o s_user.o scache.o send.o snomask.o sslproc.o substitution.o supported.o tgchange.o whowas.o lex.yy.o y.tab.o version.o -L../libratbox/src/.libs -lratbox -lcrypt -lcrypto -lfl ../libratbox/src/.libs/libratbox.so: undefined reference toEC_KEY_new_by_curve_name'
collect2: ld returned 1 exit status
make[1]: *** [ircd] Error 1
make[1]: Leaving directory `/home/kiril/charybdis/src'
make: *** [build] Error 2
kiril@vs1146:~/charybdis$

I was told on charybdis's IRC that I should refer to the irc.conf.example file to see all possible configurations and documentation for each one.

The ircd.8 man page should be corrected to point to that document instead of the missing ircd.conf.5 man page.

The configure command doesn't respect the --bindir and --libdir arguments it claims to support. Indeed, the include/config.h file hardodes a few paths, which we have to patch in the Debian package:

--- charybdis-3.3.0.orig/include/config.h
+++ charybdis-3.3.0/include/config.h
@@ -49,8 +49,8 @@

 /* dirs */
 #define DPATH   IRCD_PREFIX
-#define BINPATH IRCD_PREFIX "/bin/"
-#define LIBPATH IRCD_PREFIX "/lib/"
+#define LIBPATH IRCD_PREFIX "/lib/charybdis"
+#define BINPATH LIBPATH
 #define MODPATH MODULE_DIR
 #define AUTOMODPATH MODULE_DIR "/autoload/"
 #define ETCPATH ETC_DIR 

We need to change BINPATH because the ircd name clashes with other ircds that may be installed through other packages. The LIBPATH is changed for similar reasons.

This was originally reported as http://jira.atheme.org/browse/CHARY-3 but then lost. Note that I believe that parts of the original patch originally in the Debian package are not necessary, but I will do further testing to make sure of that.

Please allow a custom flag to be added to users who are looking to join from the Tor network. This will allow them to login while non Tor enabled accounts cannot be bruteforced by Tor connections.

This bug was reported against the Debian package, and I believe it affects upstream too.

Is this fixed in later Charybdis releases (3.4?)? This is on 3.3.0..

Current Git version of charybdis (charybdis-3.3.0-331-gfce4df5) is sending an "691 TLS is not configured" error message after successfully completing the TLS handshake.

$ gnutls-cli localhost -p 26001 --insecure -s
Processed 162 CA certificate(s).
Resolving 'localhost'...
Connecting to '::1:26001'...

- Simple Client Mode:

CAP LS
:chary.rain NOTICE * :*** Looking up your hostname...
:chary.rain NOTICE * :*** Checking Ident
:chary.rain NOTICE * :*** Found your hostname
:chary.rain NOTICE * :*** Got Ident response
:chary.rain CAP * LS :account-notify away-notify extended-join multi-prefix sasl tls
CAP REQ :tls
:chary.rain CAP * ACK :tls 
STARTTLS
:chary.rain 670 * :STARTTLS successful, proceed with TLS handshake
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject etc., etc., etc.
- Certificate[1] info:
 - subject etc., etc., etc.
*** Verifying server certificate failed...
- Successfully sent 0 certificate(s) to server.
- Session ID: 0C:DA:A4:19:DE:2C:09:58:CC:EF:3B:A7:65:69:FC:92:10:8C:38:7C:CD:80:01:20:20:25:74:5D:72:70:F8:00
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1021 bits
 - Peer's public key: 1021 bits
- Version: TLS1.2
- Key Exchange: DHE-RSA
- Cipher: AES-256-CBC
- MAC: SHA256
- Compression: NULL
:chary.rain 691 * :TLS is not configured

I can't start the server once compiled from source in /usr/local/charydbis-ircd. The logs indicated that band cannot open the sqlite database without saying which file he's trying to open.

Documentation does not state how to proceed to set one.

So far I tried to create a writeable var/ directory. Also BANDDB_PATH=/usr/local/ircd-charybdis/var/db.sqlite.

Edit: also created an empty ban.db file in etc with write permission

None seems to work.

Hello. I have an idea that will be lovely if it happen for real.
For example you have been seen many trying to flood with part/join. And i though that chan module will be a lovely leverage in this cases. So what's my idea.

[16:00:09] * someone ([email protected]) has joined #charybdis
[16:00:09] * someone ([email protected]) has left #charybdis
[16:00:09] * someone ([email protected]) has joined #charybdis
[16:00:09] * someone ([email protected]) has left #charybdis
Once when user is joined in channel has no right to part for some seconds. The seconds can be set in variable like 2/3/4/5 and so on. That can prevent that fuck`n flood.

One of the things I've noticed about chary's blacklist checking is that it doesn't allow for actions based on reply types. If an IP address is listed, it's prevented from connecting. If it's not (and the DNS server returns NXDOMAIN), the IP is allowed.

The problem with this is that many DNSBLs offer various reply types, based on the entry. For example, the popular TOR blacklist, tor.dnsbl.sectoor.de, returns 127.0.0.1 for an exact match, and 127.0.0.2 for a subnet match. As chary blocks on all replies, anyone in the same subnet as a TOR exit node is banned.

Blitzed Open Proxy Monitor is a good example of DNSBL replies. You specify the replies you wish to ban on, and a type/reason associated with the reply. This reason is then included in the ban reason (which is useful for DNSBLs that have different categories, e.g. Open Proxy, Trojan Spreader, TOR node, as the user knows more about why they have been banned).

Excerpt from BOPM sample config:

        blacklist {
       name = "rbl.efnet.org";
       type = "A record reply";
       reply {
          1 = "Open proxy";
          2 = "Trojan spreader";
          3 = "Trojan infected client";
          4 = "TOR exit server";
          5 = "Drones / Flooding";
       };
       ban_unknown = yes;
       kline = "GLINE *@%h 1d :Proxy detektovan na hostu %h";
    };

Issue #6 had @nenolod mention reducing the diff between charybdis and ircd-seven. Something from ircd-seven I want to suggest being implemented into charybdis are the global server notices. This would make administration of networks a bit easier.

17:12:23 <nyuszika7h> @raw :02H SJOIN 0 #services UltimateNate
17:12:23 <-- whiskers75 ([email protected]) has quit (charybdis.ilbelkyr.de whiskers75.co.uk)
17:12:23 <-- urandom (urandom@/dev/urandom) has quit (charybdis.ilbelkyr.de whiskers75.co.uk)

This is not just a netsplit, whiskers75.co.uk actually crashed here. (urandom is on services.urandom.eu.org, which is linked to whiskers75.co.uk.)

Hides a user's entire channel list in WHOIS from non-IRCops
I think this will be a good future module. A lot of people love this mode. So make it real.

While building the Debian package of charybdis (version 3.3.0-7.1) using our research compiler infrastructure we noticed conflicting types being used in the linked executable. This is due to _GNU_SOURCE being defined in several source files and by the config headers generated through configure, but the order of #include causes inconsistencies:

For instance, src/listener.c #includes stdinc.h, which in turn includes
ratbox_lib.h, which again includes librb-config.h - but not (!)
libratbox_config.h.

As a result, system headers expand to conflicting declarations. (This was at
least noticed for the bind function, but may extend to others.)

Best,
Michael

Debian wheezy has new hardening flags built in that make charybdis fail to compile:

gcc -fPIC -DPIC -shared -I../include -I../libratbox/include  -D_FORTIFY_SOURCE=2 -O0 -Wall -std=gnu99 -g -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security  -DIRCD_PREFIX=\"/usr\" -Wl,-z,relro core/m_kill.c -o core/m_kill.so
core/m_kill.c: In function ‘mo_kill’:
core/m_kill.c:101:5: error: format not a string literal and no format arguments [-Werror=format-security]
core/m_kill.c: In function ‘ms_kill’:
core/m_kill.c:218:3: error: format not a string literal and no format arguments [-Werror=format-security]
cc1: some warnings being treated as errors
make[2]: *** [core/m_kill.so] Erreur 1
make[2]: quittant le répertoire « /home/anarcat/src/build-area/charybdis-3.4.2/modules »

This is with:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)

that is, Debian stable. Similar results in 4.7.3 (debian sid).

Coming from #12 - now that gnutls was ripped out of Charybdis, we need a license exception to legally link against OpenSSL.

A statement such as this would be sufficient:

Charybdis is licensed under the GNU General Public License version 2 with the
addition of the following special exception:

In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with the OpenSSL
library.
You must obey the GNU General Public License in all respects for all of
the code used other than OpenSSL. If you modify file(s) with this
exception, you may extend this exception to your version of the file(s),
but you are not obligated to do so. If you do not wish to do so, delete
this exception statement from your version. If you delete this exception
statement from all source files in the program, then also delete it here.

According to mrflea, the only file that is linked against the OpenSSL code would be libratbox/src/openssl.c, so that fix should be rather trivial.

According to users on #charybdis, everything is fine with Xcode 4 and OS X 10.8.
Trying to build on 10.9 however fails with the following error:

build ==> modules
gcc -fPIC -DPIC -shared -I../include -I../libratbox/include   -O0 -Wall -std=gnu99 -g -g -O2  -DIRCD_PREFIX=\"/Users/clint/ircd\"  core/m_ban.c -o core/m_ban.so
Undefined symbols for architecture x86_64:
  "_CAP_BAN", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_CAP_TS6", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_ConfigFileEntry", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_add_conf_by_address", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_add_to_resv_hash", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_check_klines", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_check_klines_event", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_check_xlines", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_deactivate_conf", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_find_prop_ban", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_get_oper_name", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_ilog", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_kline_queued", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_m_ignore", referenced from:
      _ban_msgtab in m_ban-zwerhZ.o
  "_m_unregistered", referenced from:
      _ban_msgtab in m_ban-zwerhZ.o
  "_make_conf", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_operhash_add", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_operhash_delete", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_prop_bans", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_rb_current_time", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_rb_event_addonce", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_rb_make_rb_dlink_node", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_rb_outofmemory", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_rb_strlcpy", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_remove_reject_mask", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_resv_chan_forcepart", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_resv_conf_list", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_sendto_one_notice", referenced from:
      _m_ban in m_ban-zwerhZ.o
      _ms_ban in m_ban-zwerhZ.o
  "_sendto_realops_snomask", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_sendto_server", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_valid_wild_card", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_valid_wild_card_simple", referenced from:
      _ms_ban in m_ban-zwerhZ.o
  "_xline_conf_list", referenced from:
      _ms_ban in m_ban-zwerhZ.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [core/m_ban.so] Error 1
make: *** [build] Error 2

charybdis' bandb tool has a copy of sqlite3.c in its source directory. this makes it difficult to make sure that it is up to date and / or secure.

we use the following patch in the Debian package to link against the system library instead:

--- charybdis-3.3.0.orig/bandb/Makefile.in
+++ charybdis-3.3.0/bandb/Makefile.in
@@ -13,7 +13,7 @@ RM              = @RM@
 LEX             = @LEX@
 LEXLIB          = @LEXLIB@
 CFLAGS          = @IRC_CFLAGS@ -DIRCD_PREFIX=\"@prefix@\"
-LDFLAGS         = @LDFLAGS@
+LDFLAGS         = @LDFLAGS@ -lsqlite3
 MKDEP           = @MKDEP@ -DIRCD_PREFIX=\"@prefix@\"
 MV              = @MV@
 RM              = @RM@
@@ -39,16 +39,14 @@ PROGS       = bandb bantool
 BANDB_SOURCES =     \
   bandb.c  \
   rsdb_snprintf.c \
-  rsdb_sqlite3.c \
-  sqlite3.c
+  rsdb_sqlite3.c

 BANDB_OBJECTS = ${BANDB_SOURCES:.c=.o}

 BANTOOL_SOURCES =     \
   bantool.c    \
   rsdb_snprintf.c \
-  rsdb_sqlite3.c \
-  sqlite3.c
+  rsdb_sqlite3.c

 BANTOOL_OBJECTS = ${BANTOOL_SOURCES:.c=.o}

Then of course the sqlite3.c file could be removed.

this was originally submitted as http://jira.atheme.org/browse/CHARY-6 but lost.

Someone has been decloaking the hostmasks of our opers & users, we believe they may be using this
http://decal.sdf.org/spotfedsonline/uncloakirc-freenode-atheme.txt

The changes to include/config.h made in c74836d were not carried over to include/config.h.dist, so when --enable-fhs-paths is set, the .pid and ban.db files will be located in sysconfdir rather than rundir and localstatedir as expected.

maybe an actual issue is needed, on the notifico project, to allow channels to be tested.

If you send a message to a user and you have user mode +g, they are automatically added to your /accept list. The same doesn't happen for +R though, which is pretty annoying, especially since you don't even get a notification for unidentified users messaging you.

Mostly for Red Hat users or other people with a modified OpenSSL library. cpp only checks for version number and does not take RHEL's behaviour of dumbing down libraries into account.

Currently there's an entry in README.FIRST telling Red Hat users to compile OpenSSL from scratch but a --disable-ecc flag would be nice for RHEL users who refuse to install a proper OpenSSL library.

Unfortunately I'm too unfamiliar with autoconf to do this myself.

A module hiding only your idle time. Can be settable from all , but only admins can see your actual idle.

Example:

» Nick: someone
» Real Name: bla
» Hostmask: [email protected]
» Channels: #somechan
» Server:irc.someserver.com
» Server Info:some info
» SSL: YES
» Signed on at: Thursday 04/10/2012 11:23:29
» Time idle: 6secs
» Time online: 4days 5hrs 2mins 21secs
» Authname: someone

This "Time idle: 6secs" should be not visible.