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] (Nils, is this done? -Christian)
* UDP backend (need LIBRARY to support (de)fragmentation!)
* HTTP backend
* Testing:
- + Testcases for set_quota, timeouts, disconnects, transmit_ready_cancel
- + Better coverage of gnunet-service-transport (hello validation)
+ + Testcases for set_quota, timeouts, disconnects, transmit_ready_cancel
+ + Better coverage of gnunet-service-transport (HELLO validation)
+ direct test of plugins compliance to plugin API
Databases:
should possibly try to confirm that the given address works for
us ourselves (loopback-style) before adding it to the list
[SECURITY issue]
+ + we may be able to simplify WELCOME messages (no need to add
+ addresses there anymore, but may help to learn them there anyway...).
+ + 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!
- not sure current way of doing ACKs works well-enough
with unreliable transports where the ACK maybe lost;
the "is_new" check would then possibly prevent future
and results in code replication
- should latency be included in the ReceiveCallback and
NotifyConnect or passed on request?
+ - FIXME's with latency being simply set to 0 in a few places
+ - Memory leak (running valgrind --trace-children=yes on test_transport_api:
+ ==28393== 16 bytes in 1 blocks are indirectly lost in loss record 1 of 5
+ ==28393== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
+ ==28393== by 0x52343E3: GNUNET_xmalloc_unchecked_ (common_allocation.c:62)
+ ==28393== by 0x5234389: GNUNET_xmalloc_ (common_allocation.c:53)
+ ==28393== by 0x524458A: GNUNET_NETWORK_socket_create_from_accept (network.c:289)
+ ==28393== by 0x524B2DA: ??? (server.c:332)
+ ==28393== by 0x524A4C7: ??? (scheduler.c:425)
+ ==28393== by 0x524A73D: GNUNET_SCHEDULER_run (scheduler.c:510)
+ ==28393== by 0x524FF8C: GNUNET_SERVICE_run (service.c:1326)
+ ==28393== by 0x405500: main (gnunet-service-transport.c:2645)
+ And also:
+ ==28393== 65,744 (65,728 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
+ ==28393== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
+ ==28393== by 0x52343E3: GNUNET_xmalloc_unchecked_ (common_allocation.c:62)
+ ==28393== by 0x5234389: GNUNET_xmalloc_ (common_allocation.c:53)
+ ==28393== by 0x524473E: GNUNET_NETWORK_socket_create_from_accept (network.c:323)
+ (rest of trace identical)
+
* SETUP:
- auto-generate "defaults.conf" using gnunet-setup from "config.scm"
- integrate all options into "config.scm"
- 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).
+* CORE:
+ - code currently 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)
* PEERINFO:
- have gnunet-peerinfo print actual host addresses again
- add option to gnunet-peerinfo to modify trust value
projects / oweals / gnunet.git / blobdiff