TODO

   1 PHASE #1: (Goal: settle key design questions)
   2
   3 core:
   4 - test fails with fresh /tmp directory (but passes when run a second time)
   5   problem seems to be caused by HELLO validation (unvalidated
   6   HELLO not used to connect for good, then somehow SETKEY never happens);
   7   * double-check crypto involved in HELLO validation (PONG signature check;
   8     what about MiM?  Might be trivial right now; adding source IP-address
   9     to PONG signature might help?  How would we validate that (given that
  10     we may be learning our source IP address(es) the same way...))
  11     + if we add address to transport-level PONG, we may be able to simplify
  12       WELCOME messages (no need to add addresses there anymore, right?);
  13     + we probably want some kind of voting/counting for learning IP addresses
  14       (maybe including IP addresses in ads proportional to how often others
  15        report them? we at least need some protection against >64k HELLOs!),
  16     + provide a way to give the user a list of "learned" IP addresses and
  17       a way to easily "veto" addresses off the list!
  18       => If MiM attacker uses vetoed address, blacklist the specific IP for
  19          the presumed neighbour!
  20  * Use special, non-WELCOMEing TCP-connection for HELLO/address validation;
  21     that way, we can avoid confusion between a dozen parallel validating connections
  22     and the real one, avoid queueing messages on validating connections and
  23     shut those down immediately after sending/receiving the PONG
  24     (and maybe avoid some signalling about connections to the other layers)
  25   * core notifies clients about "encrypted" connections being up well before
  26     we get the encrypted PONG; sometimes this may be OK (for topology killing
  27     unwanted connnections), but of course not in general.  I suspect we want
  28     to signal on PONG and have topology hook directly into transport to
  29     kill plaintext connections before they have a chance to become encrypted
  30     (may require minor hack in transport API)
  31
  32 Util:
  33 * improve disk API [Nils] (Nils, is this done? -Christian)
  34 * Windows: use events instead of pipes to signal select()s [Nils]
  35 * only connect() sockets that are ready (select()) [Nils]
  36   [On W32, we need to select after calling socket before
  37    doing connect etc.]
  38
  39 TESTCASES WANTED:
  40 For these functions, it would be nice if we had testcases ("make check")
  41 that would cause them to be executed and check that they are working:
  42 * gnunet-service-peerinfo:
  43   - change_host_trust / flush_trust
  44   - remove_garbage /
  45   - discard_hosts_helper / cron_clean_data_hosts
  46 * gnunet-service-transport:
  47   - try_unvalidated_addresses
  48   - lookup_address_callback
  49   - lookup_hello_callback
  50   - plugin_env_lookup_address
  51   - notify_clients_disconnect
  52   - list_validated_addresses
  53   - cleanup_validation
  54   - disconnect_neighbour
  55   - handle_set_quota
  56 * plugin_transport_tcp.c:
  57   - tcp_plugin_cancel
  58   - tcp_plugin_address_pretty_printer / append_port
  59   - tcp_plugin_set_receive_quota
  60   - delayed_done
  61 * transport_api:
  62   - GNUNET_TRANSPORT_set_qutoa / send_set_quota
  63   - hello_wait_timeout
  64   - transmit_ready
  65   - transmit_timeout
  66   - remove_from_any_list / remove_neighbour
  67   - GNUNET_TRANSPORT_notify_transmit_ready_cancel
  68 * core_api:
  69   - timeout_request
  70   - solicit_traffic / copy_and_free
  71   - GNUNET_CORE_peer_configure / produce_configure_message
  72 * gnunet-service-core:
  73   - update_window
  74   - find_client
  75   - handle_client_request_configure
  76   - set_key_retry_task
  77   - align_and_deliver
  78   - handle_transport_notify_disconnect
  79 * hostlist (everything)
  80 * topology (everything)
  81
  82
  83
  84 PHASE #2: (Goal: recover basic file-sharing functionality)
  85
  86 Datastores:
  87 * implement sqlite-based sqstore/datastore service
  88   + implement service (datastore + talks to plugin)
  89   + implement library (talks to service)
  90   + implement sqlite plugin (talks to DB)
  91   + fix testcases (make them use CPS, complete their inner workings...)
  92 * implement sqlite-based dstore services
  93   + design API
  94   + implement library (talks to service)
  95   + implement service (talks to plugin)
  96   + implement sqlite plugin (talks to DB)
  97
  98 Applications:
  99 * DHT, DV
 100 * FS / fs-libs
 101
 102
 103
 104 PHASE #3: (Goal: ready for pre-release) [completion-goal: end of 2009]
 105
 106 * testing
 107 * setup
 108 * gtk, qt GUIs
 109 * tbench
 110 * tracekit
 111 * vpn
 112
 113 Transports:
 114 * UDP backend (need LIBRARY to support (de)fragmentation!)
 115 * HTTP backend
 116 * Testing:
 117   +  Testcases for set_quota, timeouts, disconnects, transmit_ready_cancel
 118   + Better coverage of gnunet-service-transport (hello validation)
 119   + direct test of plugins compliance to plugin API
 120
 121 Databases:
 122 * sqlite, mysql & postgres backend
 123
 124
 125
 126 Minor TODO items:
 127 * UTIL:
 128   - crypto_hash: use libgcrypt (supports SHA-512 since 2003)
 129   - container_bloomfilter: improve efficiency (see FIXME)
 130 * SERVER:
 131   - inefficient memmove
 132 * TRANSPORT:
 133   - transport_api: support forcing disconnects through low quotas!
 134     (required for working F2F support!)
 135   - API: consider having core provide deadline information for each message
 136     (likely important for DV plugin which wants to loop back!)
 137   - implement transport API to pretty-print transport address
 138     + transport_api extension (API extension!)
 139     + service-transport extension (protocol extension)
 140   - add calls to statistics in various places
 141   - implement gnunet-transport (transport configurator / tester)
 142   - UPnP-based IP detection
 143     (Note: build library always, build service when libxml2/etc. are available)
 144   - instantly filter addresses from *other* peers that
 145     are *equal* to our own address + port (i.e., localhost:2086).  We
 146     no longer filter those for outgoing (helps with loopback testing
 147     and keeps the code clean), but we should filter strictly *impossible*
 148     incoming addresses!  This is for efficiency, not correctness.
 149   - We currently are happy to take any address told to us in a WELCOME
 150     to our set of addresses; we should have some minimal threshold-based
 151     scheme, limiting both the total number of addresses that we accept
 152     this way as well as requiring multiple confirmations; also, we
 153     should possibly try to confirm that the given address works for
 154     us ourselves (loopback-style) before adding it to the list
 155     [SECURITY issue]
 156   - not sure current way of doing ACKs works well-enough
 157     with unreliable transports where the ACK maybe lost;
 158     the "is_new" check would then possibly prevent future
 159     ACKs to be delivered, all while we're happily
 160     receiving messages from that peer!  Worse, the other
 161     peer won't generate another ACK since it thinks we're
 162     connected just fine...
 163     Key questions:
 164     + How necessary is ACKing in the first place? (alternatives?)
 165     + Should we transmit ACKs in response to every HELLO? (would that
 166       fully address the problem?)
 167   - latency measurements implemented in the transport
 168     plugins makes it only work for bi-di transports
 169     and results in code replication
 170   - should latency be included in the ReceiveCallback and
 171     NotifyConnect or passed on request?
 172 * SETUP:
 173   - auto-generate "defaults.conf" using gnunet-setup from "config.scm"
 174   - integrate all options into "config.scm"
 175   - change config-file writing to exclude options set to default values
 176 * ARM:
 177   - implement exponential back-off for service restarts
 178   - better tracking of which config changes actually need to cause process restarts by ARM.
 179   - have way to specify dependencies between services (to manage ARM restarts better)
 180   - client-API is inefficient since it opens a TCP connection per service that is started
 181     (instead of re-using connections).
 182 * PEERINFO:
 183   - have gnunet-peerinfo print actual host addresses again
 184   - add option to gnunet-peerinfo to modify trust value
 185 * POSTGRES-DB:
 186   - finish postgres implementation; simplify other SQLs using new stats
 187 * HTTPS transport
 188   - PolariSSL for MHD?
 189   - https integration
 190 * GAP improvements:
 191   - active reply route caching design & implementation of service,
 192     gap extension!
 193 * HOSTLIST:
 194   - implement advertising of hostlist URL
 195   - implement learning of hostlist URLs
 196
 197
 198
 199 => PRE-RELEASE
 200
 201 PHASE #4: [completion-goal: mid 2010]
 202 * Documentation
 203 * new webpage
 204
 205
 206
 207
 208 Stuff to remember:
 209 * Features eliminated from util:
 210   - threading (goal: good riddance!)
 211   - complex logging features [ectx-passing, target-kinds] (goal: good riddance!)
 212   - complex configuration features [defaults, notifications] (goal: good riddance!)
 213   - network traffic monitors (goal: eliminate)
 214   - IPC semaphores (goal: d-bus? / eliminate?)
 215   - second timers
 216   - DNS lookup (goal: have async service; issue: still need synchronous resolution in places, current code may not be portable)
 217   => code shrunk from 61 files to 34, 22k LOC to 15k LOC, 470k to 330k (with symbols)
 218 * New features in util:
 219   - scheduler
 220   - service and program boot-strap code
 221 * Major changes in util:
 222   - more expressive server (replaces selector)
 223 * Open questions:
 224   - how to integrate scheduler with GTK event loop!
 225
 226
 227
 228 Test coverage:
 229 * UTIL      : 78.7%
 230 * HELLO     : 93.7%
 231 * ARM       : 69.9%
 232 * RESOLVER  : 60.4%
 233 * STATISTICS: 82.8%
 234 * PEERINFO  : 71.5%
 235 * TRANSPORT : 70.9%
 236 * CORE      : 65.8%
 237 ===================
 238 * TOTAL     : 74.9%
 239
 240 Not yet tested:
 241 * HOSTLIST  :  0.0%
 242 * TOPOLOGY  :  0.0%