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
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
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
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
