-
- o Negative integer encoding
-
-
-lib/silcpkix
-============
-
- o PKIX implementation
-
-
-lib/silcserver
-==============
-
- o (Re)write commands/command replys.
-
- o (Re)write notify handling.
-
- 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 Another SERVER_SIGNOFF opt/bugfix: Currently the signoff is
- sent to a client if it is on same channel as the client that
- signoffed. However, the entire SERVER_SIGNOFF list is sent to
- the client, ie. it may receive clients that was not on the
- same channel. This is actually against the specs. It must be
- done per channel. It shouldn't receive the whole list just
- because one client happened to be on same channel.
-
- o MAYBE: The SilcChannelClientEntry can be:
- SilcUInt32 address;
- SilcUInt32 mode;
-
- where address is SilcClientEntry address XOR SilcChannelEntry.
- You can get SilcClientEntry by doing client = chl->address XOR channel,
- and SilcChannelEntry by doing channel = chl->address XOR client.
- As long as the other pointer is always available when accessing the
- structure this can be done.
-
- o Add reference counters to all Silc*Entry structures
-
- o SERVICEs support (plugin, SIM)
-
- 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!
-
- 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 (Fix this to 0.9.x).
-
- o Related to above. If multiple JOINs are received in sequence perhaps
- new key should be created only once, if the JOINs are handeled at the same
- time. Now we create multiple keys and never end up using them because
- many JOINs are processed at the same time in sequence. Only the last
- key ends up being used.
-
- o The CMODE cipher & hmac change problem (#101).