updates
[silc.git] / TODO
1 TODO/bugs in Irssi SILC client
2 ==============================
3
4  o GETKEY server will save the serverkey to the same filename as the 
5    connected server and thus destroys the key.
6
7  o GETKEY server will show first, "there is no such nickname".
8
9  o Add local command to switch the channel's private key when channel has
10    several private keys.  Currently sending channel messages with many
11    keys is not possible because changing the key is not possible by the
12    user.
13
14  o JOINing to +a (requires passphrase to JOIN) does not work on autojoin.
15    Seems the passwords in the .silc/config has no effect.
16
17  o Add local commands to list the current server and client public keys
18    that the user has.  And a local command to dump the contents of the
19    public key to the screen.  Something like LISTKEYS, SHOWKEY...
20
21  o We should get rid of the clientconfig.[ch] in Irssi SILC and move the
22    cipher, hash, hmac and pkcs configuration to the Irssi SILC's config
23    file.
24
25  o Add PERL scripting support from Irssi CVS.
26
27  o Extend the /HELP command to support sub commands or something.  So
28    that user can say /help set mutual_authentication they would get
29    help of the mutual_authentication setting.
30
31  o Set different kind of settings, like, /set mutual_authentication,
32    /set key_exchange_timeout, /set conn_auth_timeout etc etc.
33
34
35 TODO/bugs In SILC Client Library
36 ================================
37
38  o Remove the assert from silc_client_file_send.
39
40  o Having @ in nickname will crash the client after changing the nickname
41    back without the @.
42
43  o The PRIVATE_MESSAGE_KEY packet is not handled (it is implemented 
44    though).  This should be added and perhaps new client operation
45    should be added to notify application that it was received and
46    set the key only if application wishes to set (accept the key) it.
47
48  o should /nick nick and /nick Nick cause the Nick to be Nick@host becase
49    it used to be nick??
50
51  o When changing own nickname and there exists a same nickname the library
52    can give the client now nickname in format nick@host.  This is new
53    behaviour and maybe should be removed.  The changer should always
54    get the one it wants and not have the formatted nickname.
55
56  o Remove the command destructor all together from the client, it is
57    not needed and its usage is buggy when the context is registered
58    to multiple pending commands.
59
60  o Additions to do after protocol version 1.1:
61
62         o Fix the NICK_CHANGE notify handling not to create new entry
63           for the changed client, but take the nickname from the notify
64           (removes need for resolving as well).  Protocol TODO entry 3.
65
66         o Add support for list of errors in command replies.  Protocol
67           TODO entry 1.
68
69
70 TODO/bugs In SILC Server
71 ========================
72
73  o removing other's modes on channel seems to be possible due to some
74    cumode bug.
75
76  o Topic notifications seem to go double times occasionally to a channel.
77
78  o Add hashed passwords to silcd.conf file.
79
80  o Backup router related issues
81
82         o Channel user mode changes are notified unnecessarely when
83           switching to backup router on router crash.
84
85  o Add a timeout to handling incoming JOIN commands.  It should be 
86    enforced that JOIN command is executed only once in a second or two
87    seconds.  Now it is possible to accept n incoming JOIN commands
88    and process them without any timeouts.  THis must be employed because
89    each JOIN command will create and distribute the new channel key
90    to everybody on the channel.
91
92  o New configuration file format must be added.  The new one will be
93    done using the dotconf config library (lib/dotconf).  The following
94    tasks relates closely to this as well and must be done at the same time
95    when adding the new config file format:
96
97         o Server says that it is able to listen on multiple ports but
98           currently that is bogus.  It can, but internals are for single
99           server.
100
101         o Protocol execution timeouts are hard coded, should be
102           configurable.
103
104         o IP address fields in configuration file should accept mask
105           format as well, IP/MASK, and not just plain IP.
106
107  o If client's public key is saved in the server (and doing public key
108    authentication) then the hostname and the username information could
109    be taken from the public key.  Should be a configuration option!
110
111
112 TODO/bugs In SILC Libraries
113 ===========================
114
115  o WIN32 silc_net_create_connection_async does not work the same way
116    than on Unix.  Do it with threads on WIN32.  The function works but
117    is not actually async currently.
118
119  o Rewrite the lib/silcsim/silcsim.h.  The SilcSimContext should be
120    private and silc_sim_alloc should take necessary arguments.
121
122
123 TODO in SILC Protocol
124 =====================
125
126 Current protocol version is 1.0.  However, it is far from being perfect,
127 and needs to include additional features.  Following protocol TODO entries
128 describe new stuff to be added to protocol versions 1.x.
129
130  1. Re-define the Status Payload: it is now 16 bits, split it into two
131     8 bits fields.  First field includes status types from 0 - 9 and
132     10 - n *if* it is not an list of errors.  If it is list of errors then
133     the first field includes 1, 2 and/or 3, and the second field includes
134     the error status 10 - n.  This way it is possible to send multiple
135     errors (list of errors) and we have a way to tell the receiver that
136     there will be other errors as well.  The second field is used only
137     if there is list of errors.  If normal status, or normal (single)
138     error status the second field is set to zero, and must be ignored.
139     Hence, the status works same way as now except for list of errors.
140     To be included in protocol version 1.1.
141
142  2. Define that WHOIS and IDENTIFY commands must send list of errors
143     if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was
144     requested and was not found.  Each unfound entry must cause an error
145     command reply to the sender.  Also define that errors must be sent
146     *after* sending successfully found entries (this way receiver may
147     ignore them).  To be included in protocol version 1.1.
148
149  3. Define the NICK_CHANGE notify to send the changed nickname as a new
150     third argument.  This will make the NICK_CHANGE notify handling easier
151     in the receiver's end (client primarily) since it removes the
152     requirement that receiver must resolve (using IDENTIFY or WHOIS) the
153     new Client ID received in the notify (because of the new nickname is
154     unknown).  To be included in protocol version 1.1.
155
156  4. Add "request parameters" or similar to the WHOIS command, which can
157     be used to request various parameters (something not returned by
158     standard WHOIS command) about clients (info that could be fetched
159     even from clients).  Additional specification (or appendix) should 
160     be done to define the payload and the parameters.  It could be used
161     to make the WHOIS command support various search conditions as well.
162     This would be the way to extend the WHOIS command to support various
163     new features without always making the command incompatible to previous
164     version.  To be included in protocol version 1.1.
165
166  5. Inviting and banning by public key should be made possible.  To be
167     included in protocol version 1.x.
168
169  6. Add perhaps SILENCE_USERS, SILENCE_OPERS channel user modes which
170     can be used to silence (moderate) normal users and opers (this set
171     only by founder).  To be included in protocol version 1.1.
172
173  7. Channel Message Payload needs slight redesining to include the IV
174     field to the MAC generation of the payload.  It is authenticated
175     by the packet's MAC but not by the payload's MAC.  Since the IV
176     belongs to the payload, its integrity should be protected by the
177     payload MAC and not alone by packet MAC.  To be included in protocol 
178     version 1.1.
179
180
181 TODO After 1.0
182 ==============
183
184 A rough list of stuff that is going to be done to SILC after 1.0 or at
185 least could be done.
186
187  o Implement the defined SilcDH API.  The definition is in
188    lib/silccrypt/silcdh.h.
189
190  o X.509 certificate support.  SILC protocol supports certificates and
191    it would be great to have support for them.  This is a big task as
192    support has to be made for ASN.1 as well.  I've looked into OpenSSL 
193    package as it has X.509 certificate support (and ASN.1 as well).  
194    The code does not look very good to my eye but it has some potentials.
195    This should be looked at more closely.
196
197    Naturally own SILC Certificate API has to be defined regardles what
198    the actual X.509 library is (OpenSSL X.509 or something else).  Other
199    choice is to write own X.509 library but I'm not going to do it - 
200    I can help to migrate the OpenSSL X.509 into SILC and I can help if 
201    someone would like to write the X.509 library - but I'm not going 
202    to start writing one myself.  Anyhow, the OpenSSL X.509 lib should
203    be checked.
204
205    Other package that should be checked is the NSS's X509 library,
206    which I like more over OpenSSL package.
207
208  o SSH2 public keys support, allowing the use of SSH2 public keys in
209    SILC.
210
211  o OpenPGP certificate support, allowing the use of PGP public keys
212    in SILC.
213
214  o Compression routines are missing.  The protocol supports packet
215    compression thus it must be implemented.  SILC Zip API must be
216    defined.
217
218  o Rewrite the lib/silcutil/silcprotocol.[ch] not to have [un]register 
219    functions, but to make it context based all the way.  The alloc should 
220    take as argument the protocol type and its callback (not only 
221    final callback).  It is not good that we have now global list of 
222    registered protocols.
223
224  o Optimizations in Libraries
225
226         o There is currently three (3) allocations per packet in the
227           silc_packet_receive_process, which is used to process and
228           dispatch all packets in the packet queue to the parser callback
229           function.  First allocation is for parse_ctx, second for the
230           SilcPacketContext, and third for packet->buffer where the actual
231           data is saved.
232
233           The parse_ctx allocation can be removed by adding it as a
234           structure to the SilcPacketContext.  When the SilcPacketContext
235           is allocated there is space for the parse context already.
236
237           The silc_packet_context_alloc could have a free list of
238           packet contexts.  If free packet context is found from the list
239           it is returned instead of allocating a new one.  The library
240           could at first allocate them and save them to the free list
241           until enough contexts for smooth processing exists in the list.
242           This would remove a big allocation since the structure is
243           quite big, and even bigger if it would include the parse_ctx.
244
245           The packet->buffer can be optimized too if the SilcBuffer
246           interface would support free lists as well.  Maybe such could
247           be done in the same way as for SilcPacketContext.  The
248           silc_buffer_alloc would check free list before actually 
249           allocating new memory.  Since the packets in the SILC protocol
250           usually are about the same size (due to padding) it would be
251           easy to find suitable size buffer from the free list very
252           quickly.
253
254           These naturally cause the overal memory consumption to grow
255           but would take away many allocations that can be done several
256           times in a second.
257
258         o Move the actual file descriptor task callback (the callback that
259           handles the incoming data, outgoing data etc, that is implemnted
260           in server and client separately (silc_server_packet_process and
261           silc_client_packet_proces)) to the low level socket connection
262           handling routines, and create an interface where the application
263           can register a callbacks for incoming data, outoing data and EOF
264           receiving, which the library will call when necessary.  This way 
265           we can move the data handling in one place.
266
267         o Add silc_id_str2id to accept the destination buffer as argument
268           and thus not require any memory allocation.  Same will happen
269           with silc_id_payload_* functions.
270
271  o Optimizations in Server
272
273         o Remove the big switch statement from the function 
274           silc_server_packet_parse_type and replace it with predefined
275           table of function pointers where each of the slot in table
276           represents the packet type value.
277
278           Same could be done with notify packets which has big switch 
279           statement too.  Same kind of table of notify callbacks could be
280           done as well.
281
282         o The parser callback in the server will add a timeout task for
283           all packets.  It will require registering and allocating a
284           new task to the SilcSchedule.  Maybe, at least, for server
285           and router packets the parser would be called immediately
286           instead of adding it to the scheduler with 0 timeout.  It
287           should be analyzed too how slow the task registering process
288           actually is, and find out ways to optimize it.
289
290  o Cipher optimizations (asm, that this) at least for i386 would be nice.
291
292  o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least.
293    SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled
294    in separately.