Dana Dahlstrom dana+ngIRCd@cs.ucsd.edu wrote:
Let me introduce to you 5 outstanding students who will be working with 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
You'll hear from them on this list and encounter them on #ngircd (if you 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 particular order, from (usefullness) 'very useful' to 'probably useless but fun to implement' 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 parsing succeeded (so that, in case of errors, we don't end up in some intermediate state). - 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 easier, too.
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 living connections, 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.
3- add support for IRC services. I tried to determine what needed to be done for that but i could not find _any_ real specs whatsover. So this item is probably in the ''insane difficulty'' category.
4- restore ngircds ability to talk to the irc.org irc server. 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.
5- add support for encrypted operator passwords. Note that i already implemented this in the tls-master branch, see e.g. http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/ngircd-tls.git;a=blobdiff;f... 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 approach 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').
Thats what i can think of right now. If you want to work on different things, feel free to do so. Also, if you have any questions, please contact me (either via mailing list, private mail, irc).
Thanks, Florian