Am 13.04.2008 um 13:38 schrieb Florian Westphal:
Dana Dahlstrom <dana+ngIRCd(a)cs.ucsd.edu> wrote:
> Let me introduce to you 5 outstanding students who will be working
> us on improvements to ngIRCd from now until June as part of a team
> project I'm coordinating. They are:
> Ali Shemiran
> Brandon Beresini
> Bryan Caldwell
> Eric Grunow
> Scott Perry
Welcome on board!
hear from them on this list and encounter them on #ngircd
haven't already). Please give them a warm welcome and plenty of
suggestions and feedback. There are barely 2 months left in our short
academic term, so they'll need to get working right away, and any
guidance you can offer is greatly appreciated.
Alright, here are some things that i've thought about, in no
order, from (usefullness) 'very useful' to 'probably useless but fun
and (difficulty-wise) from 'easy' to 'insane':
1- redo configuration handling.
The way its implemented now, ngircd may exit() after a /REHASH.
Thats a _BIG_ NONONO.
So, the task is (feel free to solve this differently, though):
- get rid of all the global Conf_ variables, and aggregate this
into a single "struct ngircd_conf"
- change all config parser functions so they get a struct
ngircd_conf as argument
- have all config functions write to a temporary ngircd_conf struct
and have the temporary ngircd_conf copied to the global one after
succeeded (so that, in case of errors, we don't end up in some
- change config handling so that all errors a propagated to the caller
(ie. get rid of exit() ).
This should be fairly easy, i hope, and you can (and should) send
incremental patches for each of these steps; this should make review
I agree. Sound to be the right approach and shoudn't be too complex, I
2- allow ngircd to use TCP_MD5SIG (RFC 2385) to
protect server links.
This is something that i've wondered about: Server links are long
so it should be quite realistic for someone to guess a valid sequence
number and shutting a connection down.... no?
In any case, this is probably more of the 'fun to tinker' kind,
although i _personally_ would really like to see this implemented.
Hm ... never thought about it, but why not? ;-)
Regarding Linux: versions 2.6.20 and up should support TCP-MD5. Don't
have an idea for other systems.
3- add support for IRC services. I tried to determine
what needed to
done for that but i could not find _any_ real specs whatsover. So
this item is probably in the ''insane difficulty'' category.
IRC services are most probably the most frequently requested feature
which ngIRCd is lacking. But as you say, the (different?) protocols
used by IRC services seem to be the least documented ones on the other
I started a few times trying to implement services, but gave up each
time because I wasn't able to find sufficient(!) documentation [and
don't need services by myself ...].
So I think the first step would be to decide on which services
implementation to concentrate and to get documentation on the protocol
used. Maybe it could be useful to try to contact the authors of an IRC
4- restore ngircds ability to talk to the irc.org
ngircd can talk to 2.10 versions, but 2.11 added lots of protocol
extensions that first need to be implemented. While the main goal
is certainly difficult, i think that some of the protocol extensions
are interesting on their own.
It definitely would be "nice" if ngIRCd would became compatible to
this ircd again, but I think the protocol changes are rather hughe --
and the documentation is on the same level as for services ... :-/
Are there networks out there actually running ngIRCd and irc.org-ircd
in mixed networks?
5- add support for encrypted operator passwords.
Note that i already implemented this in the tls-master
branch, see e.g.
it stores (salted) SHA-1 hashes instead of the password in the config
file. The downside of this patch was that users had to use a
passwd-tool to create the password hash and then copy/paste
that to ngircd.conf.
So this task is to (again, only a suggestion, if you think my
is crap and you can do better, doit 8-) ):
a) isolate the sha1-passwd related changes from the tls-master branch
(should be easy, you only need to look at the most recent commit in
the tls-master brach)
b) find a way to do the user interface ''properly''. This does
probably mean that the oper-related configuration goes into a
different file (also keep in mind that ngircd should be backwards
compatible, i.e. it should still understand 'plaintext-passwords').
It's always a good thing not to store passwords in plain text, so this
seems to be a good idea. But please keep in mind that ngIRCd is meant
to support "legacy systems" that could lack modern libraries like
OpenSSL. So backwards compatibility is a must.
Thats what i can think of right now.
I had a quick loog at bugzilla, our "not so much regarded" bug tracker:
We have a few bugs listed there marked as "LATER", which all could be
interesting to work on ;-)
In addition all other open bugs and enhancement-requests listed in
Bugzilla can be found here:
If you want to work on different things, feel free to
It's definitely the best thing to work on functions oneself is
Also, if you have any questions, please contact me
mailing list, private mail, irc).
You can try to contact me, too, but I would highly suggest to mail to
this list, so others can stay informed about what's going on.