aboutsummaryrefslogtreecommitdiff
path: root/scratch/NOTES
diff options
context:
space:
mode:
Diffstat (limited to 'scratch/NOTES')
-rw-r--r--scratch/NOTES91
1 files changed, 91 insertions, 0 deletions
diff --git a/scratch/NOTES b/scratch/NOTES
new file mode 100644
index 0000000..1d5d5d1
--- /dev/null
+++ b/scratch/NOTES
@@ -0,0 +1,91 @@
+Nick's goals:
+
+ go from "cautiously optimistic on the approach" to "workable" or
+ "unworkable".
+
+ come up with "my favorite tests" and verify that they're
+ implementable by me
+
+ The main criterion:
+
+ * "can a general person who is not familiar with the system write
+ a useful test?"
+
+ * "can a person with zero knowledge of the system run the
+ resulting tests?"
+
+
+Portability notes:
+
+ supported Debian & Fedora releases
+ XP & later
+ 10.5 & later
+
+ all other unixes: support on demand
+
+ marginal:
+
+ Win2k
+ OS X 10.4
+
+Tests X Networks:
+ functional tests:
+ does the network bootstrap?
+ can I reach foo.com?
+ can I reach a hidden service?
+ can I reach the client's DNS "resolver"?
+ can I use the server's DNS client?
+ no crashes are observed under any test inputs?
+ map address functionality works?
+ do all of socks 4, 4a, 5 work?
+
+ (w/ two versions of tor?)
+ (w/ tor running on three platforms?)
+
+ "run the fast machine stuff"
+ "pick up after a test failed"
+ "run a test by name"
+ "run tests in parallel"
+
+ bridge-related stuff:
+ run a network with bridges on it
+ make sure that clients can use bridges
+ make sure that bridges announce themselves to a bridge authority
+
+ testable invariants & surprises:
+ all circuits get built "correctly"
+
+ almost always, keep some clean circuits connected to useful
+ exit nodes
+
+ tricky stuff:
+ unusually configured clients
+ (i.e. options for specifying what nodes tor will use for
+ building paths)
+ stream isolation design
+ load tests
+ (short, medium, and long-term)
+ configuration transitions
+ familialy related nodes should not be used in the same circuit
+ demonstrate that, for all inputs, no crashes occur
+
+ assertions made in the man page & specs:
+ bandwidth limiting works
+ bandwidth accounting works
+ clients respect advertised exit policies
+ advertised exit policies are enforced
+
+Information flows:
+
+ what networks are statically feasible for the given tests?
+
+ are there ever flows from the tests to the networks?
+ even if there are: aren't they just "requirements"
+
+ query the network and its nodes for config data
+
+Implementation questions:
+
+ Twisted?
+ something Erlang-ish?
+ (neither of us is thrilled with expect...)