TODO/bugs in Irssi SILC client
==============================
- o Add PERL scripting support from Irssi CVS.
+ o Fix the silc_channels_join to parse the command like, with fe.
+ silc_parse_command_line, because currently it ignores all options,
+ including passphrase which makes autojoin impossible to +a channels.
+ Other important options are ignored too.
- o Add local commands to list the current server and client public keys
- that the user has. And a local command to dump the contents of the
- public key to the screen. Something like LISTKEYS, SHOWKEY...
+ o Add local command to switch the channel's private key when channel has
+ several private keys. Currently sending channel messages with many
+ keys is not possible because changing the key is not possible by the
+ user.
- o We should get rid of the clientconfig.[ch] in Irssi SILC and move the
- cipher, hash, hmac and pkcs configuration to the Irssi SILC's config
- file.
-
- o Extend the /HELP command to support sub commands or something. So
- that user can say /help set mutual_authentication they would get
- help of the mutual_authentication setting.
-
- o Set different kind of settings, like, /set mutual_authentication,
- /set key_exchange_timeout, /set conn_auth_timeout etc etc.
-
- o Add KNOCKOUT local command. It should kick an client from channel and
- set a ban for it for number of seconds.
-
- o Add KICKBAN local command. Kicks and bans the specified client.
-
- o Do some /set show_mail_notification that would show a notification
- on screen when new email is received.
+ o /cumode for unknown nick does not give any error message.
TODO/bugs In SILC Client Library
================================
- o All protocol execution timeouts are hard coded. They should be
- configurable and the Irssi SILC client should be able to set them
- with for example /set key_exchange_timeout etc. The silc_client_alloc
- should take a Params structure or something as argument.
-
- o silc_client_close_connection leaks memory. Read the XXX from code.
+ o The PRIVATE_MESSAGE_KEY packet is not handled (it is implemented
+ though). This should be added and perhaps new client operation
+ should be added to notify application that it was received and
+ set the key only if application wishes to set (accept the key) it.
- o Some of the ops->say's should be removed and moved to the application
- from the library. Go through these.
+ o Additions to do after protocol version 1.1:
- o The client library must manage somehow when receiving client that has
- same nickname, same server, same username but different Client ID than
- what we have in the cache. It is now assumed that they are different
- client but it might not be. It should at least number the clients
- using the client->num so that they can be accessed from the user
- interface separately or it could just remove the old client unless
- it is on some channels.
+ o Fix the NICK_CHANGE notify handling not to create new entry
+ for the changed client, but take the nickname from the notify
+ (removes need for resolving as well). Protocol TODO entry 3.
- o Add client library parameters or options that handle what kind of
- messages the library should print out (using `say' client operation,
- for example) and what is left for the application to print. The
- appliation could for example set that it handles all command printing
- but all error printing should be handled by the library, etc...
- This is not a showstopper.
+ o Add support for list of errors in command replies. Protocol
+ TODO entry 1.
TODO/bugs In SILC Server
========================
- o When server quits and all clients of that server are removed from all
- channels the channel keys are re-generated for all clients. This is
- a bug and should be done only once per channel after all clients of
- the server has been removed.
+ o Configuration file additions:
+
+ o Add incoming connection frequency, incoming connection frequency
+ for single IP address, key exchange frequency, key exchange
+ frequency for single IP. Add also frequency base.
- o Incomplete IPv6 support:
+ o Add hashed passwords to config file.
- o silc_server_get_users_on_channel does not support IPv6 based
- Client ID's.
- o silc_server_route_get and the route code in general supports
- only IPv4.
- o silcd/serverid.c and its routines supports only IPv4.
+ o Add rehashing support.
- o DNS/IP lookup blocks the server. This must be fixed. Check the
- resolver stuff (resolver(3), resolver(5)). Either we have to do the
- own resolver stuff (through scheduler, if possible without writing
- too much own stuff) or use threads.
+ o If server send CUMODE_CHANGE notify (like setting founder) to router
+ and router does not have founder on channel (founder is left or there's
+ no founder on channel at all), the router will accept the server's
+ founder mode change, even though it perhaps should not do that.
- o The backup router support described in the protocol specification
- should be done at some point.
+ o The router should check for validity of received notify packets from
+ servers (after all buggy servers may send notify that is actually
+ something that should have not been sent).
- o New configuration file format must be added. The new one will be
- done using the dotconf config library (lib/dotconf). The following
- tasks relates closely to this as well and must be done at the same time
- when adding the new config file format:
+ o Add a timeout to handling incoming JOIN commands. It should be
+ enforced that JOIN command is executed only once in a second or two
+ seconds. Now it is possible to accept n incoming JOIN commands
+ and process them without any timeouts. THis must be employed because
+ each JOIN command will create and distribute the new channel key
+ to everybody on the channel.
- o Server says that it is able to listen on multiple ports but
- currently that is bogus. It can, but internals are for single
- server.
+ o Backup router related issues
- o Protocol execution timeouts are hard coded, should be
- configurable.
+ o Channel user mode changes are notified unnecessarely when
+ switching to backup router on router crash.
- o IP address fields in configuration file should accept mask
- format as well, IP/MASK, and not just plain IP.
+ o Lots of statistics updating is missing around the server.
- o Connection classes should be actually implemented in
- serverconfig.c. They can be defined but they are totally
- ignored currently. And they should be redefined also.
+ o If client's public key is saved in the server (and doing public key
+ authentication) then the hostname and the username information could
+ be taken from the public key. Should be a configuration option!
TODO/bugs In SILC Libraries
===========================
- o Incomplete IPv6 support:
+ o WIN32 silc_net_create_connection_async does not work the same way
+ than on Unix. Do it with threads on WIN32. The function works but
+ is not actually async currently.
- o All network routines in lib/silcutil/silcnet.[ch] does not
- support IPv6.
- o silc_id_render supports only IPv4 based ID's in the file
- lib/silcutil/silcutil.c.
+ o Rewrite the lib/silcsim/silcsim.h. The SilcSimContext should be
+ private and silc_sim_alloc should take necessary arguments.
- o Compression routines are missing. The protocol supports packet
- compression thus it must be implemented. SILC Comp API must be
- defined. zlib package is already included into the lib dir (in CVS,
- not in distribution), but it is not used yet, and it requires some
- tweaking on the Makefiles (we want static lib not shared).
-
- o The CAST cipher is not compiled currently due to compilation errors;
- check those. Cast is in lib/silccrypt/cast.c.
-
- o All payload parsing (decoding) functions should take unsigned char *
- and uint32 as data and data length as arguments. Now some of the
- routines do already that but most of the routines use SilcBuffer.
- The SilcBuffer ones should be removed since buf->data and buf->len
- is more convenient to use. However, the silc_buffer_[un]format
- routines support only SilcBuffer so they would require reallocation
- of SilcBuffer. Maybe support for raw data (and not just SilcBuffer)
- should be added silc_buffer_[un]format_? routines. These are currently
- only cosmetic changes but at some point must be done to make the
- payload interfaces consistent.
+ o SILC RNG does not implement random seed files, and they should be
+ implemented.
- o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least.
- SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled
- in separately.
+ o The SilcSocketConnection in the SFTP interface is actually redundant
+ and should perhaps be removed. The application can save it in the
+ context it provides, which is delivered by SFTP libary to all
+ callback functions.
-TODO In SILC Protocol
-=====================
+TODO in Toolkit Documentation
+=============================
+
+Stuff that needs to be done in order to complete the Tooolkit Reference
+Manual.
- o pp-03 draft:
+ o Lots of ROBOdoc header formatting is undone in lib/silcutil, and
+ lib/silccrypt.
- o Add SILC_MESSAGE_FLAG_SIGNED flag that indicates that the
- messages is signed with the senders private key and thus can
- be verified with its public key. This is especially handy
- feature when sending privat messages without having negotiated
- private keys, thus the servers decrypts and re-ecnrypts the
- messages. Other applications exists as well.
+ o Write "Programming with Toolkit" document, describing how to build
+ Toolkit, how the build system works, where is everything, how
+ new (external) projects can be glued into Toolkit (use irssi as an
+ example), and how external projects can use Toolkit without gluing into
+ it (how to link etc), debugging, architecture, types, etc.
+
+ o Write "Platform Implementations" document to describe what platforms
+ Toolkit support, what has been implemented, what has not been, what
+ wors differently etc.
+
+
+TODO in SILC Protocol
+=====================
+
+Current protocol version is 1.0. However, it is far from being perfect,
+and needs to include additional features. Following protocol TODO entries
+describe new stuff to be added to protocol versions 1.x.
+
+ 1. Re-define the Status Payload: it is now 16 bits, split it into two
+ 8 bits fields. First field includes status types from 0 - 9 and
+ 10 - n *if* it is not an list of errors. If it is list of errors then
+ the first field includes 1, 2 and/or 3, and the second field includes
+ the error status 10 - n. This way it is possible to send multiple
+ errors (list of errors) and we have a way to tell the receiver that
+ there will be other errors as well. The second field is used only
+ if there is list of errors. If normal status, or normal (single)
+ error status the second field is set to zero, and must be ignored.
+ Hence, the status works same way as now except for list of errors.
+ To be included in protocol version 1.1.
+
+ 2. Define that WHOIS and IDENTIFY commands must send list of errors
+ if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was
+ requested and was not found. Each unfound entry must cause an error
+ command reply to the sender. Also define that errors must be sent
+ *after* sending successfully found entries (this way receiver may
+ ignore them). To be included in protocol version 1.1.
+
+ 3. Define the NICK_CHANGE notify to send the changed nickname as a new
+ third argument. This will make the NICK_CHANGE notify handling easier
+ in the receiver's end (client primarily) since it removes the
+ requirement that receiver must resolve (using IDENTIFY or WHOIS) the
+ new Client ID received in the notify (because of the new nickname is
+ unknown). To be included in protocol version 1.1.
+
+ 4. Add "request parameters" or similar to the WHOIS command, which can
+ be used to request various parameters (something not returned by
+ standard WHOIS command) about clients (info that could be fetched
+ even from clients). Additional specification (or appendix) should
+ be done to define the payload and the parameters. It could be used
+ to make the WHOIS command support various search conditions as well.
+ This would be the way to extend the WHOIS command to support various
+ new features without always making the command incompatible to previous
+ version. To be included in protocol version 1.1.
+
+ 5. Inviting and banning by public key should be made possible. To be
+ included in protocol version 1.x.
+
+ 6. Add perhaps SILENCE_USERS, SILENCE_OPERS channel user modes which
+ can be used to silence (moderate) normal users and opers (this set
+ only by founder). To be included in protocol version 1.1.
+
+ 7. Channel Message Payload needs slight redesining to include the IV
+ field to the MAC generation of the payload. It is authenticated
+ by the packet's MAC but not by the payload's MAC. Since the IV
+ belongs to the payload, its integrity should be protected by the
+ payload MAC and not alone by packet MAC. To be included in protocol
+ version 1.1.
+
+ 8. Remove the administrative commands from the protocol all together.
+ It does not make sense for the protocol to define how a server is
+ reconnected or shutdown, since they are implementation and
+ configuration issues. Besides protocol provides only limited set of
+ administrative commands and cannot define all that one could imagine.
+ To be included in protocol version 1.1.
+
+ 9. Add SILC_MESAGE_FLAG_REPLY for being other side to the
+ SILC_MESSAGE_FLAG_REQUEST. Add generic SILC_MESSAGE_FLAG_DATA, which
+ can include generic payload, which can include generic data. The
+ payload definition is left out for now. To be included in protocol
+ version 1.1.
+
+ 10. Check command reply error status types in various commands,
+ specifically NO_FOPRIV is missing from many commands. To be
+ included in protocol version 1.1.
TODO After 1.0
==============
- o Pthreads support. A lot of problems are solved with server (and with
- client as well) if we add pthread support. We can forget things such
- as non-blocking connecting etc, and we can do things such as DNS/IP
- lookups async. The server itself also benefits great deal from
- threads, especially from performance point of view.
+A rough list of stuff that is going to be done to SILC after 1.0 or at
+least could be done.
- But, this is not a small task and almost entire SILC Library has to
- be made re-entrant. Own API is probably added for the threads support
- to make changes in the future as painless as possible. So the API
- would have things like silc_mutex_lock, silc_mutex_unlock and
- friends...
+ o Implement the defined SilcDH API. The definition is in
+ lib/silccrypt/silcdh.h.
o X.509 certificate support. SILC protocol supports certificates and
it would be great to have support for them. This is a big task as
to start writing one myself. Anyhow, the OpenSSL X.509 lib should
be checked.
- o SSH2 public keys support. Maybe - not really needed but could be
- nice as SSH is widely used all over the place. SILC Protocol
- supports SSH2 public keys.
+ Other package that should be checked is the NSS's X509 library,
+ which I like more over OpenSSL package.
+
+ o SSH2 public keys support, allowing the use of SSH2 public keys in
+ SILC.
+
+ o OpenPGP certificate support, allowing the use of PGP public keys
+ in SILC.
+
+ o Compression routines are missing. The protocol supports packet
+ compression thus it must be implemented. SILC Zip API must be
+ defined.
+
+ o Rewrite the lib/silcutil/silcprotocol.[ch] not to have [un]register
+ functions, but to make it context based all the way. The alloc should
+ take as argument the protocol type and its callback (not only
+ final callback). It is not good that we have now global list of
+ registered protocols.
+
+ o Optimizations in Libraries
+
+ o There is currently three (3) allocations per packet in the
+ silc_packet_receive_process, which is used to process and
+ dispatch all packets in the packet queue to the parser callback
+ function. First allocation is for parse_ctx, second for the
+ SilcPacketContext, and third for packet->buffer where the actual
+ data is saved.
+
+ The parse_ctx allocation can be removed by adding it as a
+ structure to the SilcPacketContext. When the SilcPacketContext
+ is allocated there is space for the parse context already.
+
+ The silc_packet_context_alloc could have a free list of
+ packet contexts. If free packet context is found from the list
+ it is returned instead of allocating a new one. The library
+ could at first allocate them and save them to the free list
+ until enough contexts for smooth processing exists in the list.
+ This would remove a big allocation since the structure is
+ quite big, and even bigger if it would include the parse_ctx.
+
+ The packet->buffer can be optimized too if the SilcBuffer
+ interface would support free lists as well. Maybe such could
+ be done in the same way as for SilcPacketContext. The
+ silc_buffer_alloc would check free list before actually
+ allocating new memory. Since the packets in the SILC protocol
+ usually are about the same size (due to padding) it would be
+ easy to find suitable size buffer from the free list very
+ quickly.
+
+ These naturally cause the overal memory consumption to grow
+ but would take away many allocations that can be done several
+ times in a second.
+
+ o Move the actual file descriptor task callback (the callback that
+ handles the incoming data, outgoing data etc, that is implemnted
+ in server and client separately (silc_server_packet_process and
+ silc_client_packet_proces)) to the low level socket connection
+ handling routines, and create an interface where the application
+ can register a callbacks for incoming data, outoing data and EOF
+ receiving, which the library will call when necessary. This way
+ we can move the data handling in one place.
+
+ o Add silc_id_str2id to accept the destination buffer as argument
+ and thus not require any memory allocation. Same will happen
+ with silc_id_payload_* functions.
+
+ o Remove the `truelen' field from SilcBuffer as it is entirely
+ redundant since we can get the true length of the buffer by
+ doing buffer->end - buffer->header. Add SILC_BUFFER_TRUELEN
+ macro instead. Consider also removing `len' field too since
+ it effectively is buffer->tail - buffer->data, and adding
+ SILC_BUFFER_LEN macro can do the same. These would save
+ totally 8 bytes of memory per buffer.
+
+ Add also perhaps function silc_buffer_alloc_size that would
+ effectively do:
+
+ return silc_buffer_pull_tail(silc_buffer_alloc(size),
+ size);
+
+ to not require the user to give the pull_tail anymore.
+
+ o Optimizations in Server
+
+ o Remove the big switch statement from the function
+ silc_server_packet_parse_type and replace it with predefined
+ table of function pointers where each of the slot in table
+ represents the packet type value.
+
+ Same could be done with notify packets which has big switch
+ statement too. Same kind of table of notify callbacks could be
+ done as well.
+
+ o The parser callback in the server will add a timeout task for
+ all packets. It will require registering and allocating a
+ new task to the SilcSchedule. Maybe, at least, for server
+ and router packets the parser would be called immediately
+ instead of adding it to the scheduler with 0 timeout. It
+ should be analyzed too how slow the task registering process
+ actually is, and find out ways to optimize it.
+
+ o The SERVER_SIGNOFF notify handing is not optimal, because it'll
+ cause sending of multiple SIGNOFF notify's instead of the one
+ SERVER_SIGNOFF notify that the server received. This should be
+ optimized so that the only SERVER_SIGNOFF is sent and not
+ SIGNOFF of notify at all (using SIGNOFF takes the idea about
+ SERVER_SIGNOFF away entirely).
+
+ o Add SilcAsyncOperation to utility library. Any function that takes
+ callback as an argument must return SilcAsyncOperation.
+
+ o Add DSS support.
o Cipher optimizations (asm, that this) at least for i386 would be nice.
+
+ o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least.
+ SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled
+ in separately.
projects / silc.git / blobdiff