ngIRCd Users

ngircd@lists.barton.de

424 Diskussionen

ngIRCd 20.2
by Alexander Barton 18 Feb '13

18 Feb '13

Hello ngIRCd'ers! Sebastian Köhler discovered a severe bug in ngIRCd 20 and 20.1 which can be exploited by arbitrary users to crash the daemon and to lead to denial of service. So here is the next "bug fix only" release for the ngIRCd 20 series: release 20.2. Please note that all releases before 20 are NOT affected by the bug mentioned above. But in the end, all installations should upgrade, ngIRCd 20.2 is the most complete release we have so far, and there should be no reasons to stay with old versions -- besides distributions not having newer releases ... Besides the fix for the DoS mentioned above, ngIRCd 20.2 contains other fixes. The complete ChangeLog lists the following changes: • Security: Fix a denial of service bug in the function handling KICK commands that could be used by arbitrary users to to crash the daemon. • WHO command: Use the currently "displayed hostname" (which can be cloaked!) for hostname matching, not the real one. In other words: don't display all the cloaked users on a specific real hostname! • configure: The header file "netinet/in_systm.h" already is optional in ngIRCd, so don't require it in the configure script. Now ngIRCd can be built on Minix 3 again :-) • Return better "Connection not registered as server link" errors: Now ngIRCd returns a more specific error message for numeric ERR_NOTREGISTERED(451) when a regular user tries to use a command that isn't allowed for users but for servers. • Don't report ERR_NEEDMOREPARAMS(461) when a MDOE command with more modes than nicknames is handled, as well as for channel limit and key changes without specifying the limit or key parameters. This is how a lot (all?) other IRC servers behave, including ircd2.11, InspIRCd, and ircd-seven. And because of clients (tested with Textual and mIRC) sending bogus MODE commands like "MODE -ooo nick", end-users got the expected result as well as correct but misleading error messages ... • Correctly detect when SSL subsystem must be initialized and take outgoing connections (server links!) into account, too. • autogen.sh: Enforce serial test harness on GNU automake >=1.13. The new parallel test harness which is enabled by default starting with automake 1.13 isn't compatible with our test suite. And don't use "egrep -o", insetead use "sed", because it isn't portable and not available on OpenBSD, for example. More information can be found on the homepage <http://ngircd.barton.de/> and its mirror <http://ngircd.berlios.de/>. The primary download locations are: • <ftp://ftp.berlios.de/pub/ngircd/> • <http://ngircd.barton.de/pub/ngircd/> Regards Alex

2 2

Don't disconnect on overlong lines?
by Brett Smith 15 Feb '13

15 Feb '13

Hi folks, Over the past month or so I've received complaints from multiple users, using different clients, about the fact that ngIRCd disconnects them when they send lines longer than the RFC permits. It seems like most ircds simply truncate the line, and this behavior is commonly expected. I think this is something that clients really ought to be more careful about, but unfortunately there are still too many that aren't, and it feels bad to me to punish the user with a disconnect for not manually counting their bytes. Would all consider truncating the line, or some other less disruptive way to handle this case? Maybe the disconnect behavior could stay when STRICT_RFC is defined. Thanks, -- Brett Smith

1 0

Print recent chat messages on user joining a channel
by Xiaohao.M 02 Feb '13

02 Feb '13

Hi all, Does anyone know how to let ngircd prints the latest 10 or 20 history messages on a user joining a channel? For the 'recent-offline-message-push', is that working with server side or just some bot could do? *Thank you,* *Xiaohao (Kevin)*

2 1

FYI: Status of ngircd in Debian
by Christoph Biedl 15 Jan '13

15 Jan '13

Hi, just wanted to let you know about two recent uploads: * ngirc-20.1 is now available in the "experimental" archive. Don't worry about that name, this has just a Debian-internal reason: To keep "unstable" available just in case the version 19.2-2 there might need an update for the upcoming wheezy release. Once this has happened, hopefully in the next four or six weeks, uploads will enter "unstable" as usual. * A backport of 19.2 for squeeze aka "stable", full version is '19.2-2~bpo60+1', will become available through debian-backports soon, probably during the next hours. For the (almost-)complete list of available versions of ngircd in Debian, see <http://packages.debian.org/search?keywords=ngircd>. The backport is still missing, this too should change within the next hours. Cheers, Christoph, with the ngircd Debian maintainer hat on

1 1

Colloquy 2.3 mishandles &channel messages with ngIRCd 20.1
by Brett Smith 07 Jan '13

07 Jan '13

Hi again, I know I have the SSL thread open, and I'll get to that in a bit, but this issue is even weirder (and unfortunately harder to work around). After our upgrade to ngIRCd 20.1, users using Colloquy 2.3 basically cannot use server-local &channels. The client renders any public messages sent to those channels as private messages from the sender. In other words, messages that should show up in the &channel pane end up in a private query pane instead. We haven't received any similar reports from other clients, and even Colloquy 2.4 is reported to work correctly, so this seems like a client-specific bug. But this all worked fine in ngIRCd 19.2, so I'm wondering if anyone has any ideas about what might have changed server-side that could trigger this? Thanks in advance, -- Brett Smith

2 2

ngIRCd 20.1 can't make SSL server connections with GnuTLS
by Brett Smith 07 Jan '13

07 Jan '13

Hi everyone, I deployed ngIRCd 20.1 on our server yesterday and ran into a hiccup. I built ngIRCd with these flags: ./configure --enable-ipv6 --with-gnutls --with-pam We're running two servers, and the second makes a server connection to the first with SSLConnect=yes. This all worked fine in 19.2, but in 20.1 the connection doesn't take. It looks like ngIRCd fails to initialize GnuTLS correctly in this case. Here's the logs on the second server, the one making the connection—this all happens in one second: ngircd[27581]: Preparing to establish a new server link for "hostname" ... ngircd[27581]: Establishing connection for "hostname" to "192.168.1.1:6697" (192.168.1.1), socket 14 ... ngircd[27581]: Libgcrypt warning: missing initialization - please fix the application ngircd[27581]: gnutls_handshake: Insufficient credentials for that request. ngircd[27581]: SSL connection on socket 14 failed! ngircd[27581]: Shutting down connection 14 (Can't connect!) with 192.168.1.1:6697 ... ngircd[27581]: Client unregistered (connection 14): Can't connect! ngircd[27581]: Connection 14 with 192.168.1.1:6697 closed (in: 0.0k, out: 0.0k). And in case it helps, on the server receiving the connection: ngircd[27517]: Accepted connection 27 from 192.168.1.2:54547 on socket 9. ngircd[27517]: gnutls_handshake: A TLS packet with unexpected length was received. ngircd[27517]: Shutting down connection 27 (SSL accept error, closing socket) with 192.168.1.2:54547 ... ngircd[27517]: Client unregistered (connection 27): SSL accept error, closing socket ngircd[27517]: Connection 27 with 192.168.1.2:54547 closed (in: 0.0k, out: 0.0k). Best regards, -- Brett Smith

3 5

ngIRCd 20.1
by Alexander Barton 02 Jan '13

02 Jan '13

Hello all, and happy new year! About two and a half week ago, ngIRCd 20 has been released. And today, I packaged the first bug fix release, ngIRCd 20.1: Release 20 included an very ugly bug which can be triggered when the configuration option "OperCanUseMode" is active and an IRC Operator tries to enforce modes on an user in a channel where the IRC Op itself isn't a member of: ngIRCd most probably will crash (and display an assertion, when compiled with debug code enabled) ... This is a severe bug, but can't be triggered by regular users. So even if you have "OperCanUseMode" enabled, but never use this functionality as IRC Operator, don't worry too much. And don't worry at all if "OperCanUseMode" is disabled in your setup, which is the default. But long story short, everybody should upgrade to ngIRCd 20.1 ;-) In addition to this bug fix, there have been a few code cleanups and fixes for the build system, for example when building on Cygwin. Full ChangeLog: • Allow ERROR command on server and service links only, ignore them and add a penalty time on all other link types. • Enforced mode setting by IRC Operators: Only check the channel user modes of the initiator if he is joined to the channel and not an IRC operator enforcing modes (which requires the configuration option "OperCanUseMode" to be enabled), because trying to check channel user modes of a non-member results in an assertion when running with debug code or could crash the daemon otherwise. This closes bug #147, thanks to James Kirwill <james.kirwill(a)bk.ru> for tracking this down! • Fix build system to cope with spaces in path names. • Code cleanups, mostly to fix build warnings on Cygwin. More information can be found on the homepage <http://ngircd.barton.de/> and its mirror <http://ngircd.berlios.de/>. The primary download locations are: • <ftp://ftp.berlios.de/pub/ngircd/> • <http://ngircd.barton.de/pub/ngircd/> And as always (hey I love cut, copy & paste!): please report any bugs, problems, and regressions to this mailing list or directly using the bug tracker. Or connect to the "official" IRC channel #ngircd on irc.barton.de: <irc://irc.barton.de/ngircd> – thanks! Regards Alex

1 0

Atheme services and XOP
by David Woodfall 30 Dez '12

30 Dez '12

I seem to be having problems with certain modules in Atheme, which are connected to XOP. Is there anything I need to set in the ngircd.conf to turn on XOP? [28/12/2012 17:58:48] atheme 7.0.5 is starting up... [28/12/2012 17:58:48] Module chanserv/owner requires owner support, refusing to load. [28/12/2012 17:58:48] module_load(): module /usr/modules/chanserv/owner init failed [28/12/2012 17:58:48] Module chanserv/protect requires protect support, refusing to load. [28/12/2012 17:58:48] module_load(): module /usr/modules/chanserv/protect init failed [28/12/2012 17:58:48] Module chanserv/quiet requires a ban-like mode +q, refusing to load. [28/12/2012 17:58:48] module_load(): module /usr/modules/chanserv/quiet init failed [28/12/2012 17:58:48] module_load(): module /usr/modules/groupserv/main is already loaded [at 0x15dd3e0] [28/12/2012 17:58:48] opensex: data format version is 11. [28/12/2012 17:58:48] groupserv: opensex data schema version is 4. [28/12/2012 17:58:48] pid 10970 [28/12/2012 17:58:48] running in background mode from /usr As you can see from the output, it Atheme thinks that ngircd doesn't support owner, protect or quiet, which according to the changelog was added to ngircd around 20rc1 -- Studioware http://www.studioware.org

2 1

ngircd 20 auf Pogoplug Pro: works
by Götz Hoffart 26 Dez '12

26 Dez '12

Hi, ngircd 20 builds fine on a Pogoplug Pro (ARM-based mini computer) with ArchLinuxARM (rolling release of today). the executable works ("runs") as expected --+ tests run successfully ("make check") --+ | ngIRCd compiles ("make") --+ | | ./configure works --+ | | | | | | | Platform HW OS Compiler ngIRCd Date C M T R See --------------------------- --- ------ ---------- ------ -------- - - - - --- armv6l/unkn./linux-gnueabi PPP ArchLA gcc4.7.2 20 12-12-25 Y Y Y Y (5) armv6l/unkn./linux-gnueabi RBP DSquee gcc4.4.5 19.1 12-06-04 Y Y Y Y (5) armv7l/unkn./linux-gnueabi CBX Ubuntu gcc4.4.3 19.1 12-04-29 Y Y Y Y (5) hppa2.0w-hp-hpux11.11 J67 HPUX11 gcc4.2.3 14.1 09-07-22 Y Y Y Y i386/pc/solaris2.11 VMF Nexent gcc4.2.3 19.1 12-05-29 Y Y Y Y (4) i386/unknown/netbsdelf1.6.2 386 NetBSD gcc2.95.3 18 11-07-10 Y Y Y Y i386/unknown/freebsd4.1.1 VMF FrBSD4 gcc2.95.2 0.8.3 12-07-07 Y Y Y Y i386/unknown/freebsd4.1.1 VMF FrBSD4 gcc2.95.2 19.2 12-07-07 Y N N N (3) i386/unknown/freebsd4.1.1 VMF FrBSD4 gcc2.95.2 19.2 12-09-04 Y Y Y Y (4) i686/pc/linux-gnu VMF Lin1.2 gcc2.7.2 19.1 12-05-30 Y Y Y Y (1) m68k/hp/hp-ux9.10 400 HPUX9 Orig.HPUX 0.7.x 03-04-30 Y Y Y Y mipsel/unknown/linux-gnu CQu DEtch gcc4.1.2 18 11-07-05 Y Y N Y (1) mipsel/unknown/linux-gnu CQu DLenny gcc4.4.5 18 11-07-30 Y Y Y Y (1) powerpc/apple/darwin7.9.0 iB3 MacOSX gcc3.3 19.1 12-05-22 Y Y Y Y (3) powerpc/apple/darwin8.11.0 PM5 MacOSX gcc4.0.1 18 11-07-02 Y Y Y Y (3) x86_64/apple/darwin12.0.0 MBA OSX108 gcc4.2.1 19.2 12-07-26 Y Y Y Y (3) x86_64/unknown/linux-gnu VMF OrcLin gcc4.4.6 20~rc2 12-12-08 Y Y Y Y (1) HW Computer Type CPU/MHz RAM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PPP = Pogoplug Pro ARM v6l, Dual-Core 128 RBP = Raspberry Pi ARM1176JZF-S/700 224 CBX = Solid-Run CuBox Marv. Armada 510/800 768 J67 = HP 9000 J6750 PA-RISC 8700+/2x875 16384 VMF = vmWare Fusion - 64 386 = Intel i80386 Intel i80386/25 32 400 = HP 400t (A1630A) Motorola 68030/50 40 CQu = Cobalt Qube2 RM5231 256 iB3 = Apple iBook G3 IBM PowerPC 750fx/800 640 PM5 = Apple PowerMac G5 IBM PowerPC 970FX/1800 4096 MBA = MacBook Air 11" 2011 Intel Core i7-2677M/1800 4096 OS ~~~ DEtch = Debian Etch 4.0 DLenny = Debian Lenny 5.0 DSquee = Debian Squeeze 6.0 Lin1.2 = Linux Kernel 1.2.13 FrBSD4 = FreeBSD 4.1.1 i386 OrcLin = Oracle Enterprise Linux, 64 Bit, Kernel 2.6.39-200.24.1.el6uek.x86_64 <https://s1.hoffart.de/ngircd-platforms.txt> Regards Götz

1 0

ngircd-19.2 to ngircd-20 upgrade produces "Bad server password" for all connecting clients
by lists＠packetmail.net 19 Dez '12

19 Dez '12

Hello, After updating to ngircd-20 from ngircd-19.2 with the same build options, all connecting clients are rejected with "Bad server password". The configuration file remained unchanged between the ngircd-20 upgrade. Am I missing something obvious? The server password is made of [0-9A-Za-z\x5e]{22} ngircd-20 was compiled with the same flags as ngircd-19.2: ./configure --enable-ipv6 --with-openssl CFLAGS="-Wall -D_FORTIFY_SOURCE=2 -O2 -fPIE -pie -fstack-protector" Syslog support: yes Enable debug code: no zlib compression: yes IRC sniffer: no Use TCP Wrappers: no Strict RFC mode: no IDENT support: no IRC+ protocol: yes IPv6 protocol: yes I/O backend: "epoll(), select()" PAM support: no SSL support: openssl libiconv support: no No errors or oddities are reported in /var/log/syslog and the start-up looks to be normal. Revering to 19.2 restores connectivity despite the "password too long" warning. Dec 19 09:00:20 localhost ngircd[1906]: /usr/local/etc/ngircd.conf, line 33: Value of "Password" too long! Dec 19 09:00:20 localhost ngircd[1906]: ngIRCd 20-IPv6+IRCPLUS+SSL+SYSLOG+ZLIB-i686/pc/linux-gnu started. Dec 19 09:00:20 localhost ngircd[1906]: Using configuration file "/usr/local/etc/ngircd.conf" ... Dec 19 09:00:20 localhost ngircd[1906]: Configuration option "DHFile" not set! Dec 19 09:00:20 localhost ngircd[1906]: OpenSSL 1.0.1 14 Mar 2012 initialized. Dec 19 09:00:20 localhost ngircd[1906]: Changed root and working directory to "/var/chroot". Dec 19 09:00:20 localhost ngircd[1907]: Running as user unknown(65534), group unknown(65534), with PID 1907. Dec 19 09:00:20 localhost ngircd[1907]: Running with root directory "/var/chroot". Dec 19 09:00:20 localhost ngircd[1907]: IO subsystem: epoll (hint size 100, initial maxfd 100, masterfd 4). Dec 19 09:00:20 localhost ngircd[1907]: Created pre-defined channel "#channel" Dec 19 09:00:20 localhost ngircd[1907]: Now listening on [0::]:1643 (socket 7). Dec 19 09:00:20 localhost ngircd[1907]: Now listening on [192.168.1.1]:1643 (socket 8). Dec 19 09:04:51 localhost ngircd[3177]: /usr/local/etc/ngircd.conf, line 33: Value of "Password" too long! Dec 19 09:04:51 localhost ngircd[3177]: ngircd 19.2-SYSLOG+ZLIB+SSL+IRCPLUS+IPv6-i686/pc/linux-gnu started. Dec 19 09:04:51 localhost ngircd[3177]: Using configuration file "/usr/local/etc/ngircd.conf" ... Dec 19 09:04:51 localhost ngircd[3177]: Configuration option "SSLDHFile" not set! Dec 19 09:04:51 localhost ngircd[3177]: OpenSSL 1.0.1 14 Mar 2012 initialized. Dec 19 09:04:51 localhost ngircd[3177]: Changed root and working directory to "/var/chroot". Dec 19 09:04:51 localhost ngircd[3178]: Running as user unknown(65534), group unknown(65534), with PID 3178. Dec 19 09:04:51 localhost ngircd[3178]: Running with root directory "/var/chroot". Dec 19 09:04:51 localhost ngircd[3178]: IO subsystem: epoll (hint size 100, initial maxfd 100, masterfd 4). Dec 19 09:04:51 localhost ngircd[3178]: Created pre-defined channel "#channel" Dec 19 09:04:51 localhost ngircd[3178]: Now listening on [0::]:1643 (socket 7). Dec 19 09:04:51 localhost ngircd[3178]: Now listening on [192.168.1.1]:1643 (socket 8). Any insight or help is appreciated. Thank you for your time and efforts around ngircd. Respectfully, Nathan

2 12

Springe zur Seite:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

ngIRCd Users