You can change the images used by replacing them in the app-root/repo/static directory.
I'm not sure where the copyright message you're referring to is. To replace it, you'd have to figure out where in the anarki code it's being generated, and override it in main.arc.
news.arc is one of the libraries that comes with arc, and is a branch of the source for Hacker News and the Arc Forum. It defines all of the functions related specifically to the news site, and is what allows you to run a clone of the forum. It's located in the lib folder of the anarki repo.
main.arc is the launch script I included in my arc-openshift repository. It just sets a few variables, and then launches the news server with the right parameters. It's located in the root directory of the arc-openshift repo.
Other files of interest are the arc libraries srv.arc and app.arc. srv.arc sets up a web server, and app.arc adds extra utilities for things like user management, etc.
The news.arc code writes to files. It doesn't use an SQL database.
---
Even without SQL, code injection is something to worry about. The Arc codebase is a breeding ground for exactly this kind of issue, since it rarely does string escaping. Let's see...
HTML injection (XSS attacks): This is the kind of injection news.arc primarily needs to worry about. Almost every string it passes around is used directly as an HTML code snippet. Fortunately, every user input is sanitized thanks to the form-generating utilities in app.arc.
Shell injection: Make sure that any directory paths passed to (ensure-dir ...) are already shell-escaped. (Arc also invokes the shell in a few other places, but those don't need any extra escaping.)
Format string injection: Be careful about file paths passed to (tofile ...). Everything after the last slash must be a valid 0-argument format string. The format string syntax is described at http://docs.racket-lang.org/reference/Writing.html.
Arc injection: The prompt.arc webapp is explicitly designed to let admin users evaluate their own Arc code on the server. If an attacker gained access to this page, it would be worse than any other kind of code injection. Because of this, I don't recommend running prompt.arc on a production site. (If it can't be helped, I recommend at least using HTTPS so admin login credentials and commands can't be intercepted by a man-in-the-middle attack.)
Yeah, that's something I'm trying to think about with the current project that I'm working on. Part of why I brought up mongodb support. Maybe something like datomic would be better.
Starting with simple files is actually really convenient and takes very little effort. Only fixing things that need fixing is a good way to make progress quickly, but it is a little disconcerting not to have many options to switch to.
Maybe building a simple arc-based database would be a good idea, but that also distracts from solving the actual problems I'm working on. Which did not initially include making a new database, as much fun as that would be.
I was working on a simple git-based data storage system for arc as part of my 'metagame' project. Not exactly designed for multi-server use though.
