GODS only modules can be triggered by a non-identified user on a GODS nick

[Chownie]

* auREAX is now known as manhose
<manhose> SICPBot, ignore chown
<manhose> SICPBot, stop ignoring auREAX
<manhose> SICPBot, stop ignoring auREAX_
<manhose> SICPBot, ignore manhose
* manhose is now known as auREAX

[ciraga]

We could check and store hostnames, ie. pass hostname to authorize.isAuthorized(nickname, hostname) and then just register the hostname as well in GODS list, admin module would add/remove users nick/host aswell. Both nick/host or just host would be needed for True.
Can't think anything seriously wrong with this approach, besides some hassle if multiple hostnames/nicks.

[ctrlcctrlv]

Hostmasks aren't permanent (unless you use a virtual host, but those can be changed too).

Most servers send a message like this upon /whois:

11:57:47 Rizon --> :irc.pantsuland.net 311 copypaste auREAX ~expunged PRIVATE.ADDRESS.CBLK.RFC1918.IANA.RESERVED * :aurawks
11:57:47 Rizon --> :irc.pantsuland.net 312 copypaste auREAX *.rizon.net :Where are you?
11:57:47 Rizon --> :irc.pantsuland.net 307 copypaste auREAX :has identified for this nick
11:57:47 Rizon --> :irc.pantsuland.net 671 copypaste auREAX :is using a secure connection
11:57:47 Rizon --> :irc.pantsuland.net 318 copypaste aureax :End of /WHOIS list.

It would be much better to search for has identified for this nick instead. I've used other bots that do it a different way and it sucked.

[ciraga]

The issue with checking the identified part is, do we really want to send /whois every time some one spams admin command(even if we had a register for "seen" nicks, it would do it for anyone else). It seems pretty inefficient. Also a related issue is that bhottu was designed with rizon as the use scenario, but we should go in the direction of catering networks that don't have registration services as well. I see hostname&nick checking as a way to not do password authentication(which is a option btw.) So the problem in my case is, that the user has no way to identify himself with the bot if he uses a network which does not do registrations and the users host is not registered with the bot or someone else could use the same host and nick to represent another user(ie. schools).

[ctrlcctrlv]

Abuse is a very valid point that I didn't consider. I'd much prefer a password to hostmask-based identification, though (which I thought was ruled out). With hostmasks the bot owner would have to keep changing the GODS config option to fit the masks. Letting a user send a password is much better and can be automated by modern clients.

(Also, just another comment, when I first started working on the bot it didn't work anywhere but Rizon as it scanned for a Rizon-only code to identify with. I fixed that in this commit. So the bot should really move in a more interoperable direction.)

[ciraga]

Allright, let's discuss the pwd option, since it brings trouble as well. If we have only one root pwd, this will cause issues in social sense(we are talking about irc), if one root user gets denied of access, how would we deal with that? At a quick glance it seems that we need 1 root pwd and rest should be custom based on creation and stored in a DB, which only the root can control. So only root can add/remove admins, and upon addition a pwd will be send to the user who is "promoted". The problem here is that this is getting more and more complex, but this would solve most of the security issues regarding this.

[ctrlcctrlv]

I think that's way too complex. There is no need for an IRC-accessible root password at all. The root user is already in control of the machine and can edit the DB as they choose with SQL or with the MySQL command line tool.

My proposal is:

• Remove the GODS option. For configuring the first admin, a simple script can be written to insert that first record in the DB. It can also be done in SQL. There's no need for GODS at all.
• Add a password field to the current admins database.
• On login, users send a PRIVMSG to the bot with the text "identify password".
• If the password is successful, send them a NOTICE that it was. (Do not reply back with a PRIVMSG as this will cause a new query window to open in most clients, which is undesirable.) Likewise, send a NOTICE if it wasn't.

[Mechazawa]

you can do a WHO query to check the flags the user has.
If the user has the r flag it means he's authed.

 def who(self, who):
        self._lsend('WHO %s' % (who.split()[0]))
        resp = ""
        while not "352" in resp:
            resp = self._lrecv()
        match = re.match(':\S+ \d+ \S+ \S+ ~(\S+) (\S+) \* (\S+) (\S+) :\d+ (\S+)', resp)
        return {
            "user": match.group(1),
            "host": match.group(2),
            "nick": match.group(3),
            "mode": match.group(4),
            "name": match.group(5)
        }

[Nyubis]

Fixed it: 1ac0830