Hello again,
On our site, we have a few users with hyphens in their usernames. They
haven't been able to log in to ngIRCd because of the validity tests in
<http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=6680…>.
I understand that other ircds use similar checks, but this somewhat
limits the value of PAM integration. I've prepared
<https://gitorious.org/~bretts/ngircd-irc-daemon/bretts-ngircd/commits/more-…>,
which still has some limits that I think are obviously justified (some
by the RFC :) ) but is otherwise more permissive. I'd be interested to
hear what you think of it.
Thanks,
--
Brett Smith
Hello folks,
I'm a sysadmin at W3C, and we're looking at using ngIRCd to serve our
private staff IRC channel, requiring users to authenticate through PAM.
Our initial tests with this have been encouraging, and I really like
how clean ngIRCd is, but we have hit a couple of corner cases with
authentication I wanted to ask about.
First, users who have passwords with spaces in them can't connect. If
I've done my homework right, this seems to be a limitation of the IRC
protocol itself: when clients connect, they provide all their important
information (nick, username, password, etc.) on a space-separated line,
so the server has no choice but to parse a password with spaces as
multiple fields. Do I have that right? I'd be happy to be told I'm
wrong about this if it means I can accommodate these users better.
Second, ngIRCd allocates 21 bytes for the password buffer, which is too
short for some of our users' passwords. As far as I can tell, a maximum
password length isn't defined in the RFC or similar, so I'm guessing
this limitation is largely historical. I've patched ngIRCd locally to
#define CLIENT_PASS_LEN to 64, which seems to be working with no ill
effects. Would you be willing to consider a patch like this upstream?
We'd love to be running stock ngIRCd without any patches, even one as
trivial as this.
Thank you,
--
Brett Smith
