aboutsummaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2009-07-08 22:11:46 +0000
committerChristian Grothoff <christian@grothoff.org>2009-07-08 22:11:46 +0000
commit191131b599cc0dc1219930221f84155b870ec6cd (patch)
treed52ea99dbcd8f3ebe4a886bedd81c59d5fbb2ffb /TODO
parented5070624e71754775c514124a1f18eff8e16944 (diff)
downloadgnunet-191131b599cc0dc1219930221f84155b870ec6cd.tar.gz
gnunet-191131b599cc0dc1219930221f84155b870ec6cd.zip
notes_and_debugging
Diffstat (limited to 'TODO')
-rw-r--r--TODO38
1 files changed, 33 insertions, 5 deletions
diff --git a/TODO b/TODO
index 28ee22259..e9a52069e 100644
--- a/TODO
+++ b/TODO
@@ -1,12 +1,40 @@
1PHASE #1: (Goal: settle key design questions) 1PHASE #1: (Goal: settle key design questions)
2 2
3core:
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
3Util: 32Util:
4* improve disk API [Nils] 33* improve disk API [Nils] (Nils, is this done? -Christian)
5* Windows: use events instead of pipes to signal select()s [Nils] 34* Windows: use events instead of pipes to signal select()s [Nils]
6* only connect() sockets that are ready (select()) 35* only connect() sockets that are ready (select()) [Nils]
7 [Nils: I'm not sure what you mean by this; fresh sockets are always 36 [On W32, we need to select after calling socket before
8 ready for connect(), just 'write' after connect needs select AFAIK; 37 doing connect etc.]
9 please clarify. --Christian]
10 38
11TESTCASES WANTED: 39TESTCASES WANTED:
12For these functions, it would be nice if we had testcases ("make check") 40For these functions, it would be nice if we had testcases ("make check")