[IRCServices Coding] A few new bugs/suggestions

[Andrew Church]

>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;

     Fixed (I completely forgot about doing this, stupid mistake).

>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.

     Fixed.

>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

     Hm, not sure why this would segfault, but I've added checks as you
suggest to prevent @ in the nickname part or a missing hostname.  If you
can pinpoint the problem (especially if it doesn't seem to be related to
this) please let me know.

>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.

     Done.

>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.

     Good idea, done (no longer allowed to be registered or forbidden; all
other functions will just return "not registered").  Do you happen to
recall where # was mentioned wrt the httpd stuff?  (I remember writing
something to that effect, I just don't recall where, and I can't seem to
find it at the moment to fix it...)

     Thanks again for all your help and suggestions.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/