diff options
-rw-r--r-- | Makefile.am | 3 | ||||
-rw-r--r-- | README.1st | 245 |
2 files changed, 247 insertions, 1 deletions
diff --git a/Makefile.am b/Makefile.am index 0466fcc10..7fae33e0f 100644 --- a/Makefile.am +++ b/Makefile.am | |||
@@ -15,7 +15,8 @@ EXTRA_DIST = \ | |||
15 | ABOUT-NLS \ | 15 | ABOUT-NLS \ |
16 | config.rpath \ | 16 | config.rpath \ |
17 | install-sh \ | 17 | install-sh \ |
18 | acinclude.m4 | 18 | acinclude.m4 \ |
19 | README.1st | ||
19 | 20 | ||
20 | gnunetincludedir = $(includedir)/gnunet | 21 | gnunetincludedir = $(includedir)/gnunet |
21 | gnunetinclude_HEADERS = gnunet_config.h | 22 | gnunetinclude_HEADERS = gnunet_config.h |
diff --git a/README.1st b/README.1st new file mode 100644 index 000000000..d55709779 --- /dev/null +++ b/README.1st | |||
@@ -0,0 +1,245 @@ | |||
1 | The following is a list of issues with GNUnet 0.11.0 that will need to | ||
2 | be addressed before we might consider GNUnet usable. Please keep this | ||
3 | list in mind when trying out GNUnet 0.11.0! Help would of course be | ||
4 | welcome, an estimate of how much work is needed and the main impact | ||
5 | are given with each item. | ||
6 | |||
7 | |||
8 | ats: | ||
9 | * We currently select one transport per peer, but we should allow the | ||
10 | use of multiple channels concurrently (i.e. UDP + TCP at the same | ||
11 | time). Neither ATS nor transport support this today, and this requires | ||
12 | a major change in the ATS plugins and the ATS API and the overall | ||
13 | ATS/transport logic. [6-12 PM, robustness, performance] | ||
14 | |||
15 | * The current proportional ATS heuristic does not devalue increasing | ||
16 | the number of connections once we have reached saturation point, | ||
17 | possibly resulting in an excessive number of connections. | ||
18 | [1-3 PM, performance] | ||
19 | |||
20 | * The mlp/ril ATS heuristics are highly unstable and keep crashing or | ||
21 | worse, and have horrific code quality. [3-12 PM, stability, | ||
22 | performance] | ||
23 | |||
24 | |||
25 | transport: [12-48 PM overall] | ||
26 | * We should move plugins into separate processes to break an overly | ||
27 | complicated subsystem into more manageable bits. [maintainability] | ||
28 | |||
29 | * Transport plugins are currently expected to be bi-directional; the | ||
30 | API should be changed to make them uni-directional, so we could have | ||
31 | say UDP for sending but receive via say SMTP, simply because NAT | ||
32 | punching and other transports (especially SAT) simply are not | ||
33 | bi-directional. Fragmentation and ACKs should then not be done in UDP | ||
34 | plugin but at transport level. This should result in significantly: | ||
35 | - better NAT traversal | ||
36 | - faster transports (especially with the multi-transport of ATS) | ||
37 | - simplified transport plugins | ||
38 | [stability, robustness, performance] | ||
39 | |||
40 | * Transport currently does not encrypt. This has the disadvantage that | ||
41 | TCP/UDP traffic is easily identified as "GNUnet"-traffic. It would be | ||
42 | better to_also use a simple cipher (ECDHE+AEAD) in a plugin-specific | ||
43 | way (i.e. HTTPS is fine already) to minimize information leakage, even | ||
44 | if for efficiency that cipher is is not replay-protected at this level | ||
45 | (and leave true replay-protected OTR to CORE). [privacy, censorship-resistance] | ||
46 | |||
47 | * transport's 'manipulation' functions should be moved into | ||
48 | a plugin-proxy, simplifying the code. This may have | ||
49 | modest implications for testbed due to the API change. | ||
50 | [maintainability, security] | ||
51 | |||
52 | * testcases are plenty but insufficiently systematic, the changes | ||
53 | described above should also enable us to create more systematic tests. | ||
54 | [maintainability, correctness] | ||
55 | |||
56 | |||
57 | hello: | ||
58 | * The current code may leak LAN IPs (in particular IPv6 with | ||
59 | MAC) globally. We have started to put in some privisions to tag | ||
60 | addresses as loopback/LAN/WAN, but need to systemtically ensure | ||
61 | that addresses are only propagated in a useful scope and avoid | ||
62 | leaking "sensitive" address data globally. | ||
63 | [3-6 PM, privacy] | ||
64 | |||
65 | |||
66 | core: | ||
67 | * core needs to be able to communicate to other peers whether this | ||
68 | peer is high-bandwidth or on battery and thus either great for | ||
69 | relaying or really bad for relaying. Higher-level subsystems | ||
70 | could then bias their peer selection to more capable peers -- | ||
71 | this is key for going on battery-operated systems. | ||
72 | [1-3 PM, performance] | ||
73 | |||
74 | * we currently use timestamps (based on roughly-synchronized clocks), | ||
75 | challenge-response AND sequence numbers to protect against | ||
76 | replay-protection. This is overkill, and the use of timestamps | ||
77 | causes issues on OpenWRT where RTCs are often unavailable. We | ||
78 | might want to increase the nonce for challenges and get rid of | ||
79 | the roughly-synchronized clocks assumption, at least for CORE | ||
80 | (we can't avoid it for NSE). [1-3 PM, usability] | ||
81 | |||
82 | * once transport encrypts (ECDH+AES), we should simplify CORE level | ||
83 | encryption to use ECDH+Twofish(+SHA512) instead of the current | ||
84 | ECDH+AES+Twofish double-encryption. | ||
85 | |||
86 | * Mobile peers currently allow adversaries to track their users as the | ||
87 | peer's identity does not change with locations. We need a mechanism to | ||
88 | notify a mobile peer about a location change and then systematically | ||
89 | change the public key we use depending on our location. [6-12 PM, | ||
90 | privacy] | ||
91 | |||
92 | |||
93 | cadet: | ||
94 | * needs more systematic testing, ideally with a mock up of DHT | ||
95 | and core. [6-12 PM, correctness] | ||
96 | |||
97 | * flow and congestion control implementation remains incomplete; | ||
98 | should borrow more from net2o [3-6 PM, performance] | ||
99 | |||
100 | * Various optimizations, such as key material pre-computation | ||
101 | and avoiding unnecessary DHT queries should be implemented. | ||
102 | [3-9 PM, performance] | ||
103 | |||
104 | * Once transport/core use AES/Twofish for encryption, we should | ||
105 | switch CADET to use KECCAK-AEAD. | ||
106 | |||
107 | * Generally needs more benchmarking to identify performance | ||
108 | bottlenecks tune accordingly. [3-12 PM, performance] | ||
109 | |||
110 | |||
111 | nat: | ||
112 | * many known NAT traversal methods are not yet supported | ||
113 | [6-12 PM, connectivity, usability] | ||
114 | |||
115 | |||
116 | dv: | ||
117 | * dv is still not working, but currently based on SET and we | ||
118 | should simplify the design to not use SET. [3-6 PM, connectivity, | ||
119 | correctness] | ||
120 | |||
121 | |||
122 | util: | ||
123 | * Event loop instantiations for various event loops (like glib, | ||
124 | libev, libevent, etc.) should be created (and tested). This | ||
125 | will applications to be built with GNUnet using those various | ||
126 | styles of event loop handling. General support for abstracting | ||
127 | the event loop is new in 0.11.0, we just need to make broader use | ||
128 | of it. [1-3 PM, performance, usability] | ||
129 | |||
130 | * gnunet-service-resolver should use asynchronous DNS queries if | ||
131 | available. This will ensure that name resolution is not super-slow | ||
132 | when GNUnet makes various parallel DNS queries (rare, but DNS | ||
133 | queries can happen to resolve peer IP addresses for visualization). | ||
134 | [1 PM, performance, usability] | ||
135 | |||
136 | |||
137 | dht: | ||
138 | * various minor tweaks should be explored, but first we need to | ||
139 | define and find a good benchmark to see where our performance | ||
140 | bottlenecks really are today; datacache (IO subsystem) might | ||
141 | be one of them. Here, picking appropriate transaction scopes | ||
142 | and isolation levels should be an easy way to boost performance, | ||
143 | but we also need more benchmarking logic. [3-12 PM, performance] | ||
144 | |||
145 | |||
146 | set: | ||
147 | * Current implementation is not yet Byzantine fault-tolerant | ||
148 | against stuffing attack. [1-3 PM, fault-tolerance] | ||
149 | |||
150 | |||
151 | topology: | ||
152 | * quite a few different functions are squished together in one | ||
153 | subsystem here, will require some changes to address changes | ||
154 | to transport and hello discussed above [1-3 PM, correctness] | ||
155 | |||
156 | * there are more robust known ways for maintaining a random mesh, we | ||
157 | might want to explore using those [3-6 PM, robustness] | ||
158 | |||
159 | |||
160 | fs: | ||
161 | * The service should be split into two, one for user-specific and one | ||
162 | for system-specific components [3-6 PM, security, usability] | ||
163 | |||
164 | * Currently, data and files are stored in a disassociated way, | ||
165 | resulting in search results that then fail to download; need OR/RPS | ||
166 | (see below) before we can think about fixing this properly. [6-18 PM, | ||
167 | usability] | ||
168 | |||
169 | * datastore (IO subsystem) is bad at keeping the database within the | ||
170 | quota set by the user. [1-3 PM, correctness] | ||
171 | |||
172 | |||
173 | conversation: | ||
174 | * dropping 'silence' on large-buffers during replay should be | ||
175 | used to avoid accumulating latency (standard VoIP technique, | ||
176 | crucial to get it to work for real calls) [1-3 PM, usability] | ||
177 | |||
178 | * needs ring tones [1 PM, usability] | ||
179 | |||
180 | |||
181 | gns: | ||
182 | * should support hijacking arbitrary gtlds [1 PM, usability] | ||
183 | |||
184 | * should import ".fr" ccTLD and ensure implementation performs [3-6 PM] | ||
185 | |||
186 | |||
187 | multicast: | ||
188 | * implementation currently trivial and under-tested | ||
189 | |||
190 | * still uses old NTR-style API, needs to transition to MQ API | ||
191 | |||
192 | |||
193 | psyc: | ||
194 | * implementation under-tested, database performance likely in | ||
195 | need for optimization [3-12 PM] | ||
196 | |||
197 | |||
198 | social: | ||
199 | * code in need for clean up and more systematic testing [6-12 PM] | ||
200 | |||
201 | |||
202 | rps: | ||
203 | * Open research, still experimental. [3-24 PM] | ||
204 | |||
205 | |||
206 | xolotl/lake/or: | ||
207 | * Open research, still non-existent. Symmetric cipher should | ||
208 | be CHACHA. [48-120 PM] | ||
209 | |||
210 | |||
211 | No serious problems are known in: | ||
212 | * statistics | ||
213 | * nse | ||
214 | * curl | ||
215 | * revocation | ||
216 | * scalarproduct | ||
217 | * tun | ||
218 | * testbed | ||
219 | * block | ||
220 | * fragmentation | ||
221 | * consensus | ||
222 | * secretsharing | ||
223 | * pt | ||
224 | * vpn | ||
225 | * gns | ||
226 | * gnsrecord | ||
227 | * arm | ||
228 | * dns | ||
229 | * exit | ||
230 | * identity | ||
231 | * json | ||
232 | * sq | ||
233 | * my | ||
234 | * namecache | ||
235 | * namestore | ||
236 | * testing | ||
237 | * hostlist | ||
238 | * zonemaster | ||
239 | |||
240 | |||
241 | We reserve judgement (due to lack of data) on: | ||
242 | * identity-provider | ||
243 | * rest | ||
244 | |||
245 | |||