Michaela Merz wrote...
> We are experiencing a big and very annoying Problem: Some clients get
> blocked in some channels for no reason:
This sounds really weird. FWIW, I operate ngircd for a small network
of about 40 users without any of these problems.
> Just to make sure: This only happens to
Cahata wrote...
> "MODE #CHANNEL +b !" can crash the ircd ...
Besides the fact I could not reproduce this on several ngircd
installations - I'm not very happy to see something that could be some
kind of exploit code published without a prior warning. This is not
responsible disclosure. If it woul
Hello,
for reasons beyond my understanding, when
* building the ngircd Debian package (on Linux at least) and
* using the sbuild build system,
the command "ps -af" does not include the commands running inside the
sbuild system. Therefore, start-server.sh will report a fail as
getpid.sh cannot no
Alexander Barton wrote...
> Please (please!) test this release candidate and report all problems, errors,
> and regressions you encounter!
The patch attached was required to build ngircd here. Should be pretty
obvious ...
Christoph
diff --git a/src/testsuite/tests.sh b/src/testsuite/tests.s
Alexander Barton wrote...
> Hm, I think the "correct" fix is the one in commit 8061056c, no?
That one does the trick, too. RFC 1925 (1) applies. Looking briefly at
the other commits since ~rc1, I'd suggest an ~rc2 based on the current
HEAD.
A different question, was this a test whether anybody a
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 upcomin
Christoph Biedl wrote...
> * 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 versio
Alexander Barton wrote...
> release 20.2.
The Debian package failed to build on hurd-i386, see
https://buildd.debian.org/status/fetch.php?pkg=ngircd&arch=hurd-i386&ver=20.2-1~exp1&stamp=1361059386
(...)
stressing server with 5 clients (be patient!):
checking stress script ... ok.
Alexander Barton wrote...
> »We proudly present … ngIRCd 21!«
... and there's a problem in s2s connections using GnuTLS. Handshake
fails with
Target:
| SSL error: Could not negotiate a supported cipher suite. [gnutls_handshake].
and subsequently initiator:
| SSL error: A TLS packet with unexpect
Christoph Biedl wrote...
> As far as I understand the code and captured traffic, setting the
> cipher list using gnutls_priority_set in ConnSSL_Init_SSL has no
> effect. The ciphers offered in the TLS "Client Hello" packet are weak
> and appearently it's to late for
Christoph Biedl wrote...
> Since even connection manually using "gnutls-cli --priority SECURE128"
> fails I assume "SECURE128" might be a good choice for a server but a
> terrible idea for a client.
Not that easy, after some experiments in IRC we found this is
peter green wrote...
> While building ngircd on the raspbian jessie autobuilders I got a
> testsuite failure with an explicit request to report to this email
> address, so I am doing so.
>
> running misc-test ... failure!
> FAIL: misc-test
> <--snip-->
> running who-test ... failure!
> FAIL: who-
Christoph Biedl wrote...
> That's interesting since building on Debian armel and armhf went
> through without problems[1]. Requires more checking, will do. Stay
> tuned.
... aaand as I feared: The ngircd test suite relies on certain
settings in /etc/hosts. If they are not in th
Nicolas Leclercq wrote...
> Clients can connect to both nodes with SSL enabled (tested with irssi or
> znc), but the 2 servers does not want to talk together : SSL error: Could
> not negotiate a supported cipher suite. [gnutls_handshake]
>
> Packages version :
>
> libgnutls26
k0nsl wrote...
> I have compiled ngircd as per the usual steps, everything does work,
> except the most crucial bit for me - SSL.
> [26473:3 65] SSL protocol error: SSL_accept (error:140760FC:SSL
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol)
Your client is speaking plain text on the por
John Bleichert wrote...
> Should I take this up with the package maintainer?
No need for that, I'm also here.
> Jan 11 13:59:18 boogie ngircd[9566]: ngircd
> 19.2-SYSLOG+ZLIB+SSL+IRCPLUS+IPv6-x86_64/pc/linux-gnu started.
> Jan 11 13:59:18 boogie ngircd[9566]: Using configuration file
> "/etc/n
Michiel van Es wrote...
> I have noticed that my Ngircd daemon shuts down whenever a client or
> an ip makes a connection to my port and sends a bogus SSL handshake:
That doesn't look good ...
> Mar 29 03:42:06 mail ngircd[29098]: SSL protocol error: SSL_accept
> (error:140760FC:SSL routines:SS
li...@packetmail.net wrote...
> Hello, some time ago I had created some patches for a specific cipher list
> with
> ngircd. In reference to the SSLv3 issue (POODLE) the below patch also
> addresses
> this issue. The key is just adding "SSL_OP_NO_SSLv3" to the
> SSL_CTX_set_options
> function.
li...@packetmail.net wrote...
> On 10/15/2014 10:47 AM, Christoph Biedl wrote:
> > + ;CipherList = HIGH:!aNULL:@STRENGTH:!SSLv3
>
> Thank you Cristoph for your response. Are you certain this syntax is
> valid/working,
Well, it worked for me. But I wouldn't mind if more
___
ngIRCd Mailing List: ngIRCd-ML@arthur.barton.de
http://arthur.barton.de/mailman/listinfo/ngircd-ml
___
ngIRCd Mailing List: ngIRCd-ML@arthur.barton.de
http://arthur.barton.de/mailman/listinfo/ngircd-ml
[ something ate my message, second try ]
Hello,
there's a longstanding issue in ngircd, at least on (Debian) Linux
using glibc: Some tests in src/festsuite rely on a certain order of
the entries in /etc/hosts.
Appearently the first entry that points to 127.0.0.1 is returned
when getnameinfo, sam
Christoph Biedl wrote...
> Enhance ngircd's resolver to resolve 127.0.0.1 into "localhost" no
> matter what. To avoid surprises, this should be controllable by
> another command line option. Using LD_PRELOAD during the tests was a
> variant.
The latter seemed like t
Christoph Biedl wrote...
> * Integration into the auto* eco-system: Hours and hours, and still no
> avail.
Let me explain:
> +noinst_LTLIBRARIES = libpreload.la
> +
> +libpreload_la_SOURCES = \
> + getnameinfo-preload.c
> +
> +libpreload_la_LDFLAGS = \
> +
Christoph Biedl wrote...
> > +noinst_LTLIBRARIES = libpreload.la
> > +
> > +libpreload_la_SOURCES = \
> > + getnameinfo-preload.c
> > +
> > +libpreload_la_LDFLAGS = \
> > + -module -export-dynamic -avoid-version -shared
> > +
>
>
inor code style cleanup, some more error checking.
Cheers,
Christoph, beware of easter eggs
commit 34539e7e0cafe660c5f1a1670a4a5d0b20a1922e
Author: Christoph Biedl
Date: Sun Nov 2 14:48:34 2014 +0100
Optionally validate certificates on TLS server links
Based on
From: F
Daiki Akiyoshi wrote...
> However, when I use commands such as kick, it says "your privileges
> are too low". Does anyone have any idea how to fix this?
Not sure if I understood your question correctly ... there seems to be
a confusion between "IRC oper" and "channel op". The /oper command
allow
Christoph Biedl wrote...
Silly typo:
> So, assuming you've enabled "OperCanUseMode" in the [Options] section,
> try to *op* yourself
Christoph
___
ngIRCd Mailing List: ngIRCd-ML@arthur.barton.de
http://arthur.barton.de/mailman/listinfo/ngircd-ml
Hello,
at the moment ngircd fails the tests for reproducible builds in Debian
since it uses the __DATE__ and __TIME__ macros for the INFO command.
Instead of patching this out I decided to implement an optional
constant BIRTHTIME that allows you to set a time stamp for the "Birth
Date" informatio
Hello,
at the moment, ngircd fails to build against openssl 1.1 since the
configure check probes for the SSL_library_init symbol which was
removed. Since however ngircd does not use that symbol (and
appearently this did not break execution), probing for a different
function availabe in both versio
Alexander Barton wrote...
> Thanks for the patch, but sadly this doesn’t apply cleanly to the
> current Git master, because there is no „if AC_CHECK_LIB(ssl,
> SSL_new)“ in the code, most probably you did this agains an internal
> branch?
The patch was incomplete, sorry about that.
> And because
30 matches
Mail list logo
