dwhagar/snowboard

Project Snowboard - an IRC bot written in Python for the Modern IRC communities.

snowboard's Issues

SSL Fails to Verify Certs on Linux but not on Mac

Something is up with the SSL verification on Linux systems, not the Mac works fine. Not sure what it is yet.

The bot should log activity.

Right now there is no logging facility used, will need to implement one before the bot is really ready to be used long term and debugged.

Deal with Half-Ops

Snowboard should be able to detect and keep track of half-ops of users that is used by some servers (mode +h).

Identity Commands

Add commands to Snowboard to allow a user to get their own user name and the user name of someone else on IRC (if exists).

Implement a command buffer / queue to prevent flooding the server.

Need to implement a way to store up commands to be sent in the Network object and doll them out slow enough sot hat the bot never gets booted for flooding, even under heavy usage.

Need to add MODE message processing.

Snowboard doesn't yet process mode commands in channels to maintain a proper list of those who do and do not have operator or voice status.

Handle Invite Only

Snowboard should be able to handle invite-only channels. To be able to request an invite from ChanServ.

Quit Message doesn't show up on DarkMyst IRC Network

The quit message is confirmed to be sent in the correct format but doesn't show up on DarkMyst. Not sure why.

Needs to AutoOp/Voice on Identify

Snowboard should automatically op and voice on a successful ident if the user has the proper flags.

Flood Protection

The bot should implement some default form of flood protection, configured from the .ini file.

Add PM versions of Trace/Seen

Add versions of trace nick and seen that work via private message.

Need to add full suite of user manipulation commands.

Need to add commands to manage the user database from IRC, add, remove, and modify users as well as flags, access levels, etc...

Ignore List Manager

Snowboard should be able to manage an internal ignore list including time-to-live (after which a user is unignored from the bot).

Random disconnects during authentication.

Sometimes, for no apparent reason, there is a disconnect when the network.py module executes its __pingpong() routine. Gets an index out of bounds error.

Undernet Unable to Connect

The bot is unable to understand a connection to Undernet. I have not tested the other major networks (EFNet, DalNet, etc...). May have to tweak the connection protocol some, so that it gets the response code 001 (which is the first response code you get when you authenticate) and then just toss out the MOTD and wait for an empty buffer to continue to the main loop.

Any thoughts would be appreciated.

How to Handle Users

I'm having trouble deciding the best way to handle a user database. I'm really just ignorant of SQL and that seems heavy handed anyway. I only have experience with text-based file reads, sequential. Thus, I'm not entirely sure how I want to do this. Ideally it would be an SQL style database (SQL Lite?).

Thoughts would be appreciated.

Default Greeter Setting

Channels should be able to be configured with a default-greeter line, this should thus be stored in the channel setting database.

Add a seen module.

Have the bot keep track of who it has seen when. Also add to that a nick / host tracing capability.

Too many individual WHO requests

Right now each person has their own WHO requests when the bot joints, and their are duplicates. Need to find a better way to do this, to avoid duplicates and do multiple requests in the same command.

Keep Track of Channel Modes / Default Modes

Snowboard should be able to keep track of the modes in a channel and then be able to act on those modes to compose commands to maintain a default mode-set as configured.

Leverage ChanServ Identification

A WHO request should have a line in it to determine if a user is authenticated already via ChanServ. We could program Snowboard to actually check if a user is ChanServ authenticated and matches the proper hostmask to bypass the Ident command.

Handle Being Kicked

Snowboard should be able to handle being kicked. Configurable if the bot will auto-rejoin or if it should be commanded to rejoin (maybe?).

Channels list is empty after `joinChannels()`

The joinChannels() function currently looks like this:

def joinChannels(conn):
    channels = []
    for chan in BOTCHANS:
        joinChannel(conn, chan)
    return channels

While it correctly joins all the channels in BOTCHANS, it creates the channels variable as an empty list then never assigns to it... so in the end the function just returns an empty list.

The function should probably be:

def joinChannels(conn):
    return [ joinChannel(conn, chan) for chan in BOTCHANS ]

HOWEVER!

Fixing this reveals numerous other bugs, mostly in channels.py, and makes the bot unusable.

So I'm going to have to take a deep dive. I'm going to fork the project as it is, fix the joinChannels() bug, then stomp down all the other bugs it reveals one at a time.

Snowboard should have a method for clearing old names off of the master list.

Right now there is a blanket function that will just go through and remove names that are not a part of any channel. However, it occurs to me that this is a poor idea.

Right now the bot checks hosts and removes the authenticated flag (nick.authed turns False) if the host information changes when a new message comes in, but one doesn't want the bot to fill up memory with nicks that are long gone.

Considering a few options...
Having snowboard use a timer of some sort to send out WHO commands, the resulting responses should tell the bot who is still online.

We could also have this be more ad-hoc, and simply check for users who are not in channels and their online status when it processes a join / part / quit.

Ideas?

Username/Password Ident

Ident should be able to use a username/password combo to authenticate even if a hostmask does not match.

Protect against SQL Injection

Still not sure how, though I know I have done some to protect against SQL Injection attacks, I'm not sure if it enough. Though this is just a user bot, and I use password hashing of course, I think I really need to try to harden the bot against such attacks.

Bot Crashed on an Action Command containing a Channel

[16/09/17 19:34:43.882] * Thumper will probably not even be safe for upstairs, and will have to join #multiverse-attic

Traceback (most recent call last):
File "snowboard.py", line 27, in
sys.exit(snowboard.main(sys.argv[1:]))
File "/home/cyclops/snowboard/snowboard/main.py", line 255, in main
cmds = __process_responses(net, data)
File "/home/cyclops/snowboard/snowboard/main.py", line 122, in __process_responses
cmds = __get_commands(raw, net)
File "/home/cyclops/snowboard/snowboard/main.py", line 189, in __get_commands
commands += scripts.rawMessages(net, raw)
File "/home/cyclops/snowboard/snowboard/scripts.py", line 101, in rawMessages
seenCommands.rawTriggers(net, message)
File "/home/cyclops/snowboard/snowboard/seenCommands.py", line 95, in rawTriggers
seen.save(nick, host, act)
UnboundLocalError: local variable 'act' referenced before assignment

Handle Invites

Snowboard should have an option to automatically join a configured channel on invite.

Change INI Configuration from IRC

Commands to alter the INI configuration from IRC itself. Should be possible, IIRC the library we're using can write the configuration files as well.

SSL Functionality for IRC Usage

Right, so this is mostly for informational purposes.

There's a few things regarding SSL that we may need to keep in mind. Specifically, the following:

• Self-Signed but valid SSL certificates
• Certificates signed by CAs, including Let's Encrypt.
• Invalid SSL certificates.
• Not using OpenSSL, instead using TLS v1.x

Note: SSLv2.0, SSLv3.0 should not be used as they are deprecated. TLS 1.0 or above should be used, preferably at least v1.2

Depending on the version of Python that we're planning on using, this could prove to be problematic but it should theoretically work between 2.x and 3.x for Python.

Installing Python SSL may be as simple as:

• pip install ssl certifi
  OR
• pip install pyopenssl ndg-httpsclient pyasn1
• pip install urllib3[secure] if we want to have the ability to do SNI also known as Server Name Indication and certificates.

As per URLLIB3's page though:

Note: If you do this on linux, e.g., Ubuntu 14.04, you will need extra system dependencies for PyOpenSSL. Specifically, PyOpenSSL requires cryptography which will require you to install:

• build-essential
• python-dev
• libffi-dev
• libssl-dev

The package names may vary depending on the distribution of linux you are using.

Actually, considering urllib3's extensive SSL documentation... I suspect we'd have pretty good SSL coverage with urllib3.

Here's some relevant documentation:

• Python's Wiki on SSL
• URLLIB3 for Python
• Python's Security Considerations This one may apply to all versions of Python, so special care may be needed, here.
• Rackspace's developer blog on Python's SSL, which lists a fair amount of my concerns with regards to SSL. Particularly that of SNI, also known as Server Name Indication.
• Oh hey, Fedora's Documentation on TLS and Python should be extremely useful to us.

Note: Minibian, the operating system on my Raspberry Pi reports that it is using Python 2.7.9. Which in the Rackspace Developer Blog indicates that these fixes are in place, now. So most likely not a concern but worth consideration.

Make ^seen database Auto Search

Make the ^Seen command automatically search for possible nick matches when looking for a nick, should a Nick not be found.

Properly Deal with Host Information in NAMES

Some servers provide hostmask information in the output of the NAMES response from the server. This should be handled properly and the bot should detect when this happens and when it does not without the need for additional configuration.

Bot doesn't keep track of who it is.

Snowboard needs to have a variable for its current nick, even if different from the one in the configuration. This will be part of the solution to solve Issue #23 and also handle instances where a nickserv authorization fails and the bots nick is changed by the server.

Close adduser security hole.

Make it so a user cannot add levels above their own and cannot add flags they don't have unless they are admin. Even admin should not be able to add flags that they are denied.

Bot does not maintain its own connection.

The bot won't go into a reconnect cycle if the connection is dropped.

Console Channel

Add a secret, invite only channel, that the bot sits in and acts as an active console of what the bot see's and does. The bot would then redirect actions and messages to a particular channel, as configured and accept a sub-set of commands to set what channel is active in the console.

Add Dice Module

Need to add a dice module, including dice for various systems.

Add Command for Bot to Generate Hostmask

Add the ability for the bot to leverage the seen database that already exists to make a guess at a valid hostmask for a user by comparing most common hostnames to each other.

Ping Command

Give the bot the ability to ping someone else, if the user is authenticated.

Use daemon tools to daemonize Snowboard

Just have to write it and use it.

Banlist Manager

Snowboard should have a method for managing ban lists, including time until unbanning.

Needs to use an alternate nick if desired nick is in use.

Snowboard needs to properly deal with its nick being in use and then how to get said nick back.

Considering using an auto-ghosting function, would need to add options in the config file for where to identify itself with the server for its nick and if the server has that capability. Also want to add an option there to ghost itself if needed.

Implement a help system.

People will inevitably need help with commands, flags, user levels, etc.

Correct grammar for when a setting is cleared.

Correct the grammar of changing a channel setting (particularly those of topics / announcements) when the text is cleared.