Whyteboard doesn't check its integrity nor repair itself (patch)

not too sure why this is needed really?

and looking at this function, isn't it a security vulnerability in itself

def ReadHashes():
    try:
        file = open( 'hashes.db' )
        text = file.read()
        exec( text )
        return hash_dict #@UndefinedVariable
    except IOError:
        return False

Come to think of it, I'm actually not sure why it's needed; it sounded like a good idea when I was making it...

In addition, I was being a smart-aleck when I called it a "security" vulnerability. It's not like it's a game connected to a server that needs to prevent hackage/pwnage (though, as far as that goes, though I have no real experience, it seems like if the server was powerful enough to double-check the client's behavior, that wouldn't be a problem) of the client to keep things fair...

What might be done with this, is this could be split into a thread that does the checking and whatnot in the background (we don't want the startup to go any slower than it needs to, right?) and download a hash "database"/dictionary from an update server and make a rolling-update type deal (updating only the changes).

Not that it really matters in this case (source files are so small), but we might want to set up some type of diff/patch system too (that would make things really complicated though, and the implementation isn't quite too obvious to me right now).

-- we could do the updating fully client-based: where we pre-compute the hashes of all releases (starting from the first release that supports the live updating)--this would all fit in 6k for changing every single file with simple zip compression and pre-computed all of the deltas (this might sound daunting, but a python script would simplify the process of making sure all of the deltas are available).

-- otherwise, if we had some server that could run python (GAE? not exactly sure how to use it, but it sounds like it would be perfect, actually, if it's free... otherwise, a free webhost with apache python extensions would suffice), it wouldn't be hard to just store all of the hashes on the server, send the current hash to the server, then have the server compute the delta on the fly; with all of the revisions stored in a version control system, this shouldn't be a problem, just as long as we knew which hash corresponded to which revision, the server could then use a svn client to grab both the client's file from svn and the head file, generate the delta, and return that to the client.

Both seem like a better option bandwidth-wise compared to downloading a ~400kb archive and update everything, when I don't really think that much gets updated (we might even try binary deltas for the pictures and such, if we really wanted to get fancy with it)

You're right, thank you for keeping me from being too lazy; I just didn't want to have to dive into a real database module at the time, but that's a good idea; I'll get right on that.

Finally, this probably should be wxpython-ified (I'll work on that yet tonight) with fancy progress bars and all of that goodness (maybe instead of a dialog, it should be in the bottom status bar?). I need to warm up on my wx anyway; event-based programming is the shit :).

Switched from my ignorant exec()'s to JSON sexiness (#python was happy to enlighten me, once again).

I was about to use shelve, but then once they mentioned arbitrary code execution on the module doc page I though "now how is this any better than exec?"