Hello all,
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.
Here's to continuing progress!
Dana
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
Am 13.04.2008 um 13:38 schrieb Florian Westphal:
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
Welcome on board!
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.
I agree. Sound to be the right approach and shoudn't be too complex, I think.
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.
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 be 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 hand.
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 services package?
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.
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. 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').
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: http://arthur.barton.de/cgi-bin/bugzilla/index.cgi
We have a few bugs listed there marked as "LATER", which all could be interesting to work on ;-) <http://arthur.barton.de/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&bug_...
In addition all other open bugs and enhancement-requests listed in Bugzilla can be found here: <http://arthur.barton.de/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&bug_...
If you want to work on different things, feel free to do so.
Absolutely! It's definitely the best thing to work on functions oneself is interested in.
Also, if you have any questions, please contact me (either via 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.
Regards Alex
Alexander Barton alex@barton.de wrote:
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.
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?
No idea. However, there are some things that are interesting/useful. E.g. i remember someone requested opless channels (+channels, http://ircnet.irchelp.org/channel.html)
5- add support for encrypted operator passwords. Note that i already implemented this in the tls-master branch, see e.g.
[..]
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.
Absolutely. Thats why the above patchset has an sha-1 implementation taken from xyssl which is used in case openssl is not available, ie. no mandatory dependency on openssl is introduced.
We have a few bugs listed there marked as "LATER", which all could be interesting to work on ;-) http://arthur.barton.de/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&resolution=LATER&
68 (Too many pre-defined channels configured) looks easy, just replace the static array with a dynamic array (see array.h).
In addition all other open bugs and enhancement-requests listed in Bugzilla can be found here: http://arthur.barton.de/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&resolution=---
66 can be closed -- ipv6 support was added to HEAD recently 8-)
Florian
Am 13.04.2008 um 15:32 schrieb Florian Westphal:
Alexander Barton alex@barton.de wrote:
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.
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?
No idea. However, there are some things that are interesting/useful. E.g. i remember someone requested opless channels (+channels, http://ircnet.irchelp.org/channel.html)
Sure. Local channels (prefixed with "&", and not new in 2.11) could be interesing as well.
We have a few bugs listed there marked as "LATER", which all could be
interesting to work on ;-) <http://arthur.barton.de/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&bug_...
68 (Too many pre-defined channels configured) looks easy, just replace the static array with a dynamic array (see array.h).
ACK.
In addition all other open bugs and enhancement-requests listed in Bugzilla can be found here: <http://arthur.barton.de/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&bug_...
66 can be closed -- ipv6 support was added to HEAD recently 8-)
I set it to "FIXED". Thanks.
Regards Alex
Am 15.04.2008 um 13:26 schrieb Christoph Biedl:
Alexander Barton wrote...
Are there networks out there actually running ngIRCd and irc.org- ircd in mixed networks?
Yes. Asking for according support has been on my list for serveral months.
Okay, so is anybody aware of some documentation for the new protocol used by ircd-irc.org version 2.11?
Regards Alex
-
Alexander Barton -
Christoph Biedl -
Dana Dahlstrom -
Florian Westphal