+++ /dev/null
-<html>
-<style TYPE="text/css"><!-- A:link {text-decoration: none}A:visited{text-decoration:none}A:active{text-decoration:none}--></style>
-<body bgcolor="#ffffff">
-<p><br>
-<a href="index.html"><img src="silc2.jpg" border=0></a>
-<table width="70%" border="0" cellspacing="0" cellpadding="1"
-align=center>
-<tr>
-<td>
-<font face="Arial,Helvetica,Sans-serif">
-<p>
-<font size=4>
-<h1>TODO</h1>
-<p>
-<pre>
-
-TODO
-====
-
-This is more or less complete list of tasks that has to be done before
-SILC 1.0 could ever be released. It is clear that the list does not
-include all the bugs that exists. At the end of list are tasks that
-needs to be done but are probably post 1.0.
-
-Feel free to contribute if you have the ability and free time - all the
-help is really appreciated - and needed.
-
- - Pekka
-
-
-New features TODO
-=================
-
- o Extended SIM (SILC Module) support. Currently only SILC Cipher API
- and SILC Hash API may be used as SIM's. What I have in mind is to
- have extended support for SIM's so that basically any SILC API could
- be used as SIM's. This would open tremendous possiblities but
- opens also issues on security that needs to be dealt with.
-
- Some sort of SIM compilation environment should be defined so that
- the SIM's could use SILC specific symbols from the modules (which they
- cannot do currently). In the future modules could add new features
- to SILC easily with this support. I'm more thinking this from client's
- perspective to add new features to client (such as IRC support as SIM)
- but server should have the support as well. Anyhow, this is an
- interesting feature...
-
- This maybe post 1.0 task - dunno.
-
- o SIM support for other platforms than just for Linux. Apache has
- example code (code that we could use directly pretty easily) for
- other platforms.
-
- o We should replace all short, int, long, unsigned short, unsigned int,
- unsigned long with some pre-defined datatypes that really are what
- we want on all platforms. int16, uint16, int32, uint32 etc. are
- what we could use or maybe SilcInt16, SilcUInt16 etc. Also, boolean
- datatype should be defined.
-
- o More platform supports should be added. The code is pretty much
- generic but there are some parts that require porting (SIM). Also,
- some support for different platforms is needed into configure.in.
-
- o SILC requires currently GCC to work because we use GCC specific
- compilation options. Generally any compiler that supports inline
- functions and can build shared libraries (for SIMs) should work.
- These cases should be included into configure.in.
-
-
-TODO In SILC Client
-===================
-
- o Implement all commands. A lot of commands are still yet to be
- implemented. Most of them are trivial but some will require some
- planning. Go see the command.c for unimplemented commands.
-
- o Non-blocking connection on the background must be stopped if some
- other connection on same window has established. Now it is possible
- that some non-blocking connection timeouts on the background when
- we already have a working connection to some other place; things
- goes bad.
-
- o Finish WHOIS, finish JOIN and other commands that are partly
- implemented.
-
- o Input line on UI is buggy. Cursor movement etc bugs. Too lazy to
- fix it.
-
- o Logic for handling multiple same nicknames for example in private
- message sending. I guess the logic is done in server side but is
- missing from client.
-
- o Private message key setting is missing and must be implemented.
- Currently private messages are encrypted with session keys. This
- is required by the protocol.
-
- o Channel private key setting is missing and must be implemented.
- Currently there cannot be private keys for channels. Normal channel
- keys (generated by server) are used. This is required by the protocol.
-
- o I guess, public key authentication (when connecting to a server)
- is not working currently. It is just matter of loading the keys
- from file and using them (see corresponding code in server, it should
- support public key authentication already).
-
- o Multiple windows support. Basic support for multiple windows already
- exists but a lot is still missing to get it working. Also, some
- of the existing stuff probably needs to be tweaked a bit before the
- multiple windows support could be done. And of course the actual
- commands that control the windows needs to be written (/WINDDOW).
-
- o Implement /KEYMAP (or similiar) command to remap control and function
- keys.
-
- o Implement /ALIAS command to make command aliases.
-
- o Implement /set/if/do/while etc as in IRC2. Maybe post 1.0 task.
- Some scripting would be good.
-
- o Connection Authentication request resolving is missing and must be
- done. This is required by the protocol.
-
- o Key Exchange protocol's responder side is missing from client.
- Generally it is possible for the client to be responder so it should
- be implemented (See corresponding code from server). Error handling
- in the KE protocol is also in pretty bad shape in client.
-
- o Configuration file format - could be better.
-
- o Write help files for commands. Nice format for the help files should
- be selected. I'm open for ideas.
-
- o All allocations and freeing needs to be checked for memory leaks.
-
-
-TODO In SILC Server
-===================
-
- o Implement all commands on server side. A lot of commands are still yet
- to be implemented. Most of them are trivial but some will require some
- planning. Go see the command.c for unimplemented commands.
-
- 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 Length of the packet processing timeouts needs to be checked whether
- they are too short or too long. I haven't really tested whether they
- are suitable. They should be tested on high load which I haven't done
- at all yet.
-
- o INVITE command must set the channel's invite list if channel is
- invite-only 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 Command flag usage in general is not implemented yet.
-
- o Client history must be implemented. Protocol says that server must
- keep history information about clients for some period of time.
-
- o Channel flags and user modes on channels are not implemented yet as
- /MODE command is not implemented yet in client and server.
-
- o Protocol execution timeouts are hard coded, should be configurable.
-
- o serverutil.c I guess should be created for util-like functions that
- now resides in server.c, which is getting too big.
-
- o serverconfig.c and the function naming in it is inconsistent. It is
- not silc_config_server* it should be silc_server_config*. As should
- all the SilcConfigServer* types be SilcServerConfig*.
-
- o Implement DENY_CONNECTION section in serverconfig.c and in server.
-
- o Implement REDIRECT_CLIENT section in serverconfig.c and in server.
-
- o Configuration file format - could be better.
-
- o IP address fields in configuration file should accept mask format
- as well, IP/MASK, and not just plain IP.
-
- o Connection classes should be actually implemented in serverconfig.c.
- They can be defined but they are totally ignored currently.
-
- o Acceptance of incoming connections (client and server connections)
- should be checked before key exchange protocol. Currently it is
- checked at the authentication phase after KE, that is ok, but it should
- be checked before starting KE, as well.
-
- o Statistics are totally missing from the server. It would be nice
- to gather some statistics.
-
- o All allocations and freeing needs to be checked for memory leaks.
-
-
-TODO In SILC Libraries
-======================
-
- o Implement PFS (Perfect Forward Secrecy) flag in SKE (and in client and
- server, actually). If PFS is set, re-key must cause new key exchange.
- This is required by the SILC protocol.
-
- o Re-key in general is actually missing (from everywhere) and must be done.
-
- o SKE does not send correct status types. Types are defined but not
- sent.
-
- o Connection authentication protocol does not send correct status types.
- These types are not defined currently at all.
-
- o PKCS#1 style RSA public key encryption/decryption/sign/verify is
- missing, and should be added for interoperability reasons. The thing
- I've done now is bad and should be removed as soon as possible (or
- the protocol should then state the method of how they should be done).
-
- o Slow ciphers should be removed. I think we don't need more than
- the AES finalists plus blowfish and RC5.
-
- o These slow ciphers actually don't work currently as I've tested
- only the ones that are worth testing. The CBC mode on these slow
- ciphers probably don't work. No need to worry, these ciphers should
- be removed.
-
- o Scheduler needs to be analyzed on high load as it might be unfair
- towards select() because it may run timeout tasks before select() and
- after select(). If it is found to be unfair the timeout task running
- before select() should probably be removed.
-
- o On select() issue; maybe we should use poll() instead if it is
- available? poll() doesn't have max fd limit...
-
- o SIM support for SILC PKCS API needs to made so that they could be
- used as SIM's. At the same time some work is required on prime
- generation as the way it is done now sucks. Read from code for
- more (silcpkcs.h).
-
- 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 Cipher API needs to be made more consistent. Some parts of the
- code generated with current Cipher API looks really bad. Same
- is with PKCS API, even worse actually. They need to be made
- cleaner. Introducing silc_cipher_encrypt/decrypt/set_key etc.
- functions (I actually don't understand why have I left these un-done).
-
- o Scheduler should automatically allocate task queues if NULL pointers
- are passed to the silc_schedule_init. Would make initialization
- cleaner.
-
- o Packet processing routines in client and server are actually pretty
- much generic and should be moved from the client/server to the library
- as generic routines (silc_<client/server>_packet_decrypt_rest* etc).
- This requires heavy changes to the client and server.
-
- o Random Number Generator needs some tweaking. Reading /dev/random may
- block resulting slow initialization of RNG. Some other things in the
- RNG may block as well. Also, I have some pending changes to the RNG
- that needs to be commited (from Schneier's Yarrow-160 paper). They
- should make the RNG even better.
-
- o Logging should be made more generic in a way that application can
- set to where the logging is destined to. Now, it is always destined
- to stdout (or stderr) which is a bad thing for client. Ie. some
- sort of logging registration functions or similiar should be done
- (silclog.[ch] in core). The actual output of logs should be done
- by callback function in the application not in lib.
-
- o All allocations and freeing needs to be checked for memory leaks.
-
- o silc_buffer_[un]format() needs to be made more stable as it may
- crash the SILC if malformed data is sent as argument. There are a
- lot of places in client and server where we trust directly data coming
- from network and try to unformat it. The unformatting routine needs
- to be able handle situations where data sent is malformed, by mistake
- or intentionally. This is important as it is easy to crash the SILC
- now by just sending malformed data. Also, in client and server we
- must start checking the return value from silc_buffer_[un]format.
-
-
-Other Things TODO
-=================
-
- o Write manuals for server.
-
- o Write manuals for client.
-
- o Write SILC Library Reference manual. This would include all the SILC
- API's with simple examples how the functions are to be used. This is
- pretty easy to create by taking all the functions plus their comments
- from source/header files. However, same sort of reference manual
- should be written for client and server as well.
-
-
-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.
-
- 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 X.509 certificate support. SILC protocol supports certificates and
- it would be great to have support for them. This is a big task as
- support has to be made for ASN.1 as well. I've looked into OpenSSL
- package as it has X.509 certificate support (and ASN.1 as well).
- The code does not look very good to my eye but it has some potentials.
- This should be looked at more closely.
-
- Naturally own SILC Certificate API has to be defined regardles what
- the actual X.509 library is (OpenSSL X.509 or something else). Other
- choice is to write own X.509 library but I'm not going to do it -
- I can help to migrate the OpenSSL X.509 into SILC and I can help if
- someone would like to write the X.509 library - but I'm not going
- 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.
-
- o IRC support for SILC client. This would be nice to have on client
- as it could be used to connect to SILC and IRC. People wouldn't
- have to have two different clients when same would work on both.
- I'd like to see this done as SIM, after the extended SIM support
- has been added to SILC.
-
- o Cipher optimizations (asm, that this) at least for i386 would be nice.
-</pre>
-<p>
-
-</td>
-</tr>
-</table>
-</body>
-</html>
projects / silc.git / blobdiff