From 0d47952611198ef6b1163f366dc03922d20b1475 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 09:42:04 +0200 Subject: Adding upstream version 7.94+git20230807.3be01efb1+dfsg. Signed-off-by: Daniel Baumann --- todo/henri.txt | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 todo/henri.txt (limited to 'todo/henri.txt') diff --git a/todo/henri.txt b/todo/henri.txt new file mode 100644 index 0000000..cca8814 --- /dev/null +++ b/todo/henri.txt @@ -0,0 +1,41 @@ +o Proper SSL support in proxy mode. + - A naive implementation relying on the current code would probably look + horrible (at least my own attempts did). I believe that nsock should + internally be able to SSLify a plain TCP connection. It doesn't have to be + exported but it should be implemented just like the other operations. Then + it would be trivial (and clean) for the library to SSLify the channel + established by the proxy hooks. + - When redesigning nsock SSL code, keep in mind the ability to establish a SSL + session and still expose the raw TCP. That can be convenient when auditing + the SSL/TLS layer. +o Don't drop pending writes when deleting the corresponding IOD. For nsock to + behave a bit like standard BSD sockets we should flush writes on close. (OTOH + anything which isn't ack'ed has no meaning, caller can still cancel it + typically...) +o Give IODs their own methods to streamline the code and get rid of all + the special cases in nsock_core.c. This would also make it easier to + hook operations (typically: override the default iod_connect() method + to establish a proxy chain). +o Fix the read API (!) +o Profile the pcap code. It needs cleanup (for sure) and optimizations (maybe). +o Proxy authentication +o Handle socks4a + - This requires to figure out how to trigger proxy code without + resolving target hostname first. The problem is that the proxy code + is supposed to be a transparent hook of connect()... Extending the + exported API will probably be needed :( + - Async hostname resolution available from within nsock would let us + try clever tricks... I'm not sure whether nsock should provide it + or if it should simply provide an API to plug an external system. +o Socks5 support +o Some code is copied from ncat. I should move it to nbase. +o Replace event lists by more efficient data structures. Consider using + a radix tree to map event IDs to pointers. Another solution would + be to put them all into a single RB-tree (TODO: validate BSD_HACK_MODE + & stuff). Encoding the event type in the ID's MSB would let us do inorder + traversal with connect events first, then read, then write... + {NOTE: It'd be cool for the beauty of it, but my tests reveal that as of Oct. + 2013 there's no big bottleneck there.} +o Rework the filespace code to avoid unneeded data copy. Scatter/gather + I/O might be useful there. Same task can also be expressed as: "profile and + optimize the usual nmap nsock I/O patterns." -- cgit v1.2.3