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

diff --git a/TODO b/TODO
index 28ee22259..e9a52069e 100644
--- a/TODO
+++ b/TODO
@@ -1,12 +1,40 @@
 PHASE #1: (Goal: settle key design questions)
 
+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())
-  [Nils: I'm not sure what you mean by this; fresh sockets are always
-   ready for connect(), just 'write' after connect needs select AFAIK;
-   please clarify. --Christian]
+* 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")