What to test

[Jonas Carpay]

These are some of my thoughts on things that should be probably be tested. Each of these things should probably be spun into a separate issue, but they all need to be addressed at some point. We should also discuss how to actually test.

• SQL injection
  Package/platform/binary names all end up in SQL queries. sqlite-simple promises it takes care of escaping, but it can't hurt to double-check.
• Other forms of injection
  Package/platform/binary names all end up in calls to nix build. As far as I know, calling a command directly the way we do should make this pretty safe, but we should probably check
• Timing attacks/thread safety issues
  If we request a package while it's already being built by another thread, I'm not sure what happens on the nix side, but what's definitely true is that we get an SQL error. That is because both threads initially determine that the package is not present, and then afterwards try to insert it into the database. When the second thread does this, it fails because the supposedly unique triplet is already present in the database.
  This is just one example though.
• DoS
  What happens if we get a bunch of garbage requests?
  What happens if we get a bunch of requests for the same long-running, failing build? This one should actually be taken care of by the negative cache, but we should make sure that that's the case.