[IRCServices Coding] A few new bugs/suggestions

[Mark Hetherington]

1) EnableGetPass setting in Services 5.0a19 problem. The help removal when
not enabled works perfectly but the directive only affects the help messages
at the moment. The command itself is still accessible. Basically it is
missing an
 	if (EnableGetpass)
around the code in chanserv and nickserv main.c, or an
 	if (!EnableGetpass) possibly_do_some_message_then_return;

2) Minor cosmetic issue with the new oper only mention of the list command
on the Chanserv help display. Since CHAN_OPER_HELP_COMMANDS_FORBID includes
4 commands and then a reference to extra powers on DROP etc, it might look
better if the list command check and print was before the forbid command in
the help display so that the text flows correctly.

3) This problem actually happened on 5.0a18 but I have been unable to
reproduce on that version so it might still be in 5.0a19. I am reporting for
the record while I research further. From the log file:

PANIC! buffer = :gaspode2 PRIVMSG ChanServ at services.ctcp.net :akick
#xdigital add *~woody@*!*
Services terminating: Segmentation fault

When trying to reproduce myself, I did notice that services reformats the
mask to:

*~woody@*!*@*

Looking at the code, it is easy to see why it reformats in this manner, but
I wonder if this was at all contributory to the crash.

This creates a couple of suggestions in addition to the crash report.

A) Maybe it would be possible to check for the ordering of *!*@* and reject
immediately rather than creating an even more erroneous mask for entry into
the akick list. This would be helpful to users creating masks.

B) Could the mask format be added to the help for AKICK or at least a
reference to another help reference available to users that describes masks
accurately. Maybe some examples similar to those for nickserv access lists.

I will try and get as many people as possible testing the akick comand to
attempt to get a reproducable case.

While writing this, I have managed to get a different user reproducing it
with pretty much any other user. I am not sure what the pattern is since I
am still unable to produce the problem myself.

An IRCop/Services Admin with a Nickserv status of 0 can obviously manipulate
the akick list of any channel and this will produce the problem everytime.
For users to have the problem, it seems that they need to be NS status 2
(recognised by access list but not by password) to reproduce the problem. I
am still working on the exact scenario, but it does seem to be related to
NickServ level when issuing the command.


4) Although documented as an issue wrt to the httpd display, the channel '#'
seems to have various other problems that are possibly related to IRCd and
clients (for example invisible to /list regardless of oper level). This
seems to make it preferable that the channel is not actually supported by
services at all particularly if is has problems with any area of services
functionality (e.g. httpd module).

I know the simple workaround is to forbid the channel but on a new
installation, anything potentially erroneous ought to be guarded against.
The user on our network who registered that channel did it purely because it
is usually banned on networks or causes severe problems with other services
packages and appears to be an exploit that various people try to abuse. It
is encouraging that it has so little effect wrt IRCServices, but if there
are any potential long term problems, IMO it is worth addressing sooner
rather than later.


Mark.