[IRCServices] A discussion on the contents of the todo file (LONG)

[Imran Ali Rashid]

Warning: another long email... mostly due to repeating old stuff, so that
people know what is being discussed.

> >Here onwards I'll mention "Things to think about"
>
>      I should point out that many of the things listed here I myself don't
> entirely agree with, but listed anyway to consider later and hopefully
> generate comments (like these).

:-)

> >> ** "Blacklist" of evil users to prevent them from getting +o/+v
> >
> >Isn't this already there ala access list autodeop. set the nojoin level to -2 and use this at -1.
> >As far as novoice goes, it could be added the same way autodeop is there.
>
>      You're misunderstanding this.  This is not on a per-channel basis,
> but something that applies to a user or users on the entire network, no
> matter what channel they are in.  In particular, I was thinking that
> hostmasks could be used here to deal with people (or bots) who don't
> register their nicks and get other people to op/voice them.

Isn't this a channel issue, which can be dealt with using secureops and a good access
list? I mean, if they get opped and people in the channel don't like it, its a channel issue,
so why should it be considered globally.

> >> ** Warn about being kicked off after N password failures
> >
> >Why not put this in the help message? You could also send it after N-1 tries.
>
>      The second is already what I'm thinking of doing, but the first is
> a good idea as well, thanks.

No Problem :-)

> >> ** Use an easily-parsable log format (eg: <time> CS REG #chan Founder)
> >
> >Whats wrong with the current format?
>
>      It's not as easy to parse programmatically as it could be.  For
> example, some people have suggested something like:
>
> 03/02/2001:12:34:56 N R NickName user at somehost.net email at add.ress

OUCH. you're right, this is insulting to human eyes.
But if this can be parsed, whats wrong with the current format?

[Mar 19 08:29:48 2001] NickServ: aala-hazrat!Stud at altamash.hostel4.giki.edu.pk
identified for nick aala-hazrat

You can still use the first word after the braces end to know if its nickserv or not.
registered is the second word after the : if register is being talked about. I don't think
the second word starts with 'r' in any other scenario. The rest can easily be parsed
since you already know which word has the nick and mask.

>      One thing I'm considering is to (optionally, of course) keep two
> logfiles: one the same as now, and one with the new format containing
> only registrations/identifies/drops and similar events.

Ummm why another log file... As i mentioned above, it can still be parsed easily.
A little extra effort is required, but not as much as people think.

> >> OS REHASH command
> >
> >Please Please Please put this in.
> >and umm a slightly different behaviour as compared to the SIGHUP signal.
> >I refer to the fact that everyone has to identify again.
>
>      If/when I do implement a rehash feature, this is what SIGHUP will
> do (instead of restart).

Cool.
Umm "if/when"? please could u put this on the todo list? :-)
Anyone else in favour?

> >> CS Last used time for access, AKICK entries
> >
> >This is a good idea. This was even mentioned by someone recently.
> >So lets discuss it and see how many people like it.
>
>      I'm already planning to implement this in 5.0 unless there's some
> objection.

No objections

> >>NS Show services oper/admin/root status in INFO
> >
> >I don't see why this is necessary... If you want to let people know who is what, make it a separate command. But I
don't
> >think that either of the suggestions(the todo one and the one i just mentioned) is a good one.
>
>      I don't see why it's a _bad_ suggestion, though with the newer
> servers which support +a (Services admin) mode it's not as necessary
> anymore.  My aim with this is to let people know who they can go to
> when they have problems with Services--though of course that's really
> a network policy matter more than anything, I suppose.

If you want to announce who the services admin is, there are easier ways, ala
motd and logonnews. Why put it in his nickserv info. This is not a good idea
from a security point of view, and like I said, if you want something extra to let
people know who to go to, put in a separate command, that lists active services
admins and so on.

> >Even the channel founder is sometimes baffled, since he can't find out. You have to go to a services admin.
> >Why not add a command to let people know which nicks are linked to theirs(after identifying of course), and add
> >something to chanserv to let people know how a person got opped(the linked nick being a case in point).
>
>      The former is already present, though only usable by Services
> admins (NickServ LISTLINKS).  The latter has been requested by other
> people as well, and I'll look into implementing it for version 5.0.

Knew about the former, was requesting the latter :-)

> >> MS MemoServ IGNORE {ADD,DEL,LIST}
> >
> >If a person wants to irritate you and u put him on ignore, whats to stop them from getting another nick and sending
> >another memo? to help against this and cases of memo flooding, a command may be put in to get rid of the memos of a
> >certain nick.
>
>      Since you can already delete ranges of memos with a single
> command, I don't see the benefit of this.  As for the usefulness of
> IGNORE, as someone else also pointed out, ignoring user at host masks
> will prevent the register-a-new-nick problem.

Oops, forgot about that, I don't know how I missed it.
You're right. Bad suggestion.

> >> ** Add a way to send OperServ (and other?) commands from the shell
> >
> >This is defintely a big help. but how about just having a telnet session with services, since that would facilitate
an
> >easier access to commands, and is a seemingly good idea...
>
>      Although I haven't decided on exactly how, I hope to implement
> something like this for version 5.0.  Obviously, there are security
> concerns associated with allowing remote access, which I'll have to
> consider as well.

how about 127.0.0.1 access only and having a password specially set
by the services admins for this purpose via irc or otherwise, which is
encrypted. What else is a concern from a security point of view?


> >> ** Services log channel
> >Was there a recent discussion on this?
>
>      Not recent, but a long time ago there was some discussion about
> this.  As I recall, it essentially came down to the benefit of being
> able to monitor the log online (remotely) vs. the security problems of
> having Services status information broadcast on the network and the
> additional network load.  I personally think it would be better off
> not being added, but I'm open to comments.

As such, if there is access to the server on which services is hosted, then
this suggestion is useless, but if access is a problem, then this seems to
be a good idea to help with troubleshooting, and the same way, rotatelog
would seem helpful.. By the way, I know its still there via SIGUSR2 but why
was it removed from operserv?