X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=TODO;h=e9a52069eb7994a33b17d7ff3a90f39063a32112;hb=0700c60ef320c8ccbd417833441697c64d6c525c;hp=0815f1d1def5433b174fee94a1d9321331d25bf7;hpb=4d8a954dceadaced33de7d54470276e40ffd13e9;p=oweals%2Fgnunet.git

diff --git a/TODO b/TODO
index 0815f1d1d..e9a52069e 100644
--- a/TODO
+++ b/TODO
@@ -1,13 +1,40 @@
 PHASE #1: (Goal: settle key design questions)
 
-ARM:
-* Make sure ARM supports daemons (non-service background processes, see hostlist/topology)
+core:
+- test fails with fresh /tmp directory (but passes when run a second time)
+  problem seems to be caused by HELLO validation (unvalidated 
+  HELLO not used to connect for good, then somehow SETKEY never happens);
+  * double-check crypto involved in HELLO validation (PONG signature check; 
+    what about MiM?  Might be trivial right now; adding source IP-address
+    to PONG signature might help?  How would we validate that (given that
+    we may be learning our source IP address(es) the same way...))
+    + if we add address to transport-level PONG, we may be able to simplify
+      WELCOME messages (no need to add addresses there anymore, right?);
+    + we probably want some kind of voting/counting for learning IP addresses
+      (maybe including IP addresses in ads proportional to how often others
+       report them? we at least need some protection against >64k HELLOs!),
+    + provide a way to give the user a list of "learned" IP addresses and
+      a way to easily "veto" addresses off the list!
+      => If MiM attacker uses vetoed address, blacklist the specific IP for
+         the presumed neighbour!
+ * Use special, non-WELCOMEing TCP-connection for HELLO/address validation;
+    that way, we can avoid confusion between a dozen parallel validating connections
+    and the real one, avoid queueing messages on validating connections and
+    shut those down immediately after sending/receiving the PONG
+    (and maybe avoid some signalling about connections to the other layers)
+  * core notifies clients about "encrypted" connections being up well before
+    we get the encrypted PONG; sometimes this may be OK (for topology killing
+    unwanted connnections), but of course not in general.  I suspect we want
+    to signal on PONG and have topology hook directly into transport to
+    kill plaintext connections before they have a chance to become encrypted
+    (may require minor hack in transport API)
 
 Util:
-* improve disk API [Nils]
+* improve disk API [Nils] (Nils, is this done? -Christian)
 * Windows: use events instead of pipes to signal select()s [Nils]
-* only connect() sockets that are ready (select())
-* crypto_hash: use libgcrypt (supports SHA-512 since 2003)
+* only connect() sockets that are ready (select()) [Nils]
+  [On W32, we need to select after calling socket before
+   doing connect etc.]
 
 TESTCASES WANTED:
 For these functions, it would be nice if we had testcases ("make check")
@@ -58,21 +85,20 @@ PHASE #2: (Goal: recover basic file-sharing functionality)
 
 Datastores:
 * implement sqlite-based sqstore/datastore service
-  + implement library (talks to service)
   + implement service (datastore + talks to plugin)
+  + implement library (talks to service)
   + implement sqlite plugin (talks to DB)
+  + fix testcases (make them use CPS, complete their inner workings...)
 * implement sqlite-based dstore services
+  + design API
   + implement library (talks to service)
   + implement service (talks to plugin)
   + implement sqlite plugin (talks to DB)
 
 Applications:
-* implement hostlist service (need to bootstrap!)
 * DHT, DV
 * FS / fs-libs
 
-Databases:
-* have ONE backend working
 
 
 PHASE #3: (Goal: ready for pre-release) [completion-goal: end of 2009]
@@ -98,10 +124,14 @@ Databases:
 
 
 Minor TODO items:
+* UTIL:
+  - crypto_hash: use libgcrypt (supports SHA-512 since 2003)
+  - container_bloomfilter: improve efficiency (see FIXME)
 * SERVER:
   - inefficient memmove
 * TRANSPORT:
   - transport_api: support forcing disconnects through low quotas!
+    (required for working F2F support!)
   - API: consider having core provide deadline information for each message
     (likely important for DV plugin which wants to loop back!)
   - implement transport API to pretty-print transport address 
@@ -147,6 +177,8 @@ Minor TODO items:
   - implement exponential back-off for service restarts
   - better tracking of which config changes actually need to cause process restarts by ARM.
   - have way to specify dependencies between services (to manage ARM restarts better)
+  - client-API is inefficient since it opens a TCP connection per service that is started
+    (instead of re-using connections).
 * PEERINFO:
   - have gnunet-peerinfo print actual host addresses again
   - add option to gnunet-peerinfo to modify trust value
@@ -194,4 +226,17 @@ Stuff to remember:
 
 
 Test coverage:
-* UTIL: 75%, 4914 out of 6463
+* UTIL      : 78.7%
+* HELLO     : 93.7%
+* ARM       : 69.9%
+* RESOLVER  : 60.4%
+* STATISTICS: 82.8%
+* PEERINFO  : 71.5%
+* TRANSPORT : 70.9%
+* CORE      : 65.8%
+===================
+* TOTAL     : 74.9%
+
+Not yet tested:
+* HOSTLIST  :  0.0%
+* TOPOLOGY  :  0.0%