-TODO/bugs in Irssi SILC client
-==============================
+TODO for 1.2 And Beyond
+=======================
- o /USERS does not show the user modes on the channel correctly.
+NOTE: Any item that doesn't have (***DONE) in it, isn't done yet. The
+(***TESTING NEEDED) means that the item has been done but not yet properly
+tested.
- 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.
+NOTE: A TODO entry does not mean that it is ever going to be done. Some
+of the entries may be just ideas, good, bad or ugly. If you want to work
+on some of the TODO entries simply let us know about it by dropping a note
+to silc-devel mailing list or appear on 'silc' channel on SILCNet.
- 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 Add the server/router operator info to the statusbar.
+General
+=======
- o /cumode for unknown nick does not give any error message.
+ o Create apps/tutorial containing various Toolkit API tutorials.
+ o The Toolkit split. The Toolkit is to be splitted in parts. How many
+ parts and what the parts are isn't decided yet. Each part is a separate
+ software package. Current thinking is of the following:
-TODO/bugs In SILC Client Library
-================================
+ SILC Toolkit SILC protocol, client and server library
+ SILC Runtime Toolkit runtime library
+ SILC Crypto Toolkit crypto, asn1, math, skr, pgp, etc.
- 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.
+ The rationale for this is of course that other than SILC projects
+ might like to use the various libraries SILC Toolkit provides, but
+ naturally they don't want the bloat of SILC protocol related stuff.
- o Additions to do after protocol version 1.1:
+ The Runtime library in SILC Toolkit is a general purpose runtime library,
+ like Glib and APR are. The runtime library is to be developed further
+ to provide alternative to Glib and APR.
- 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.
+ The Crypto library in SILC Toolkit is a general purpose crypto library
+ providing pretty nice APIs compared to many other crypto libraries,
+ especially OpenSSL. The Crypto library is to be developed further
+ to include support for OpenPGP, X.509 and SSH2.
- o Add support for list of errors in command replies. Protocol
- TODO entry 1.
+lib/silccore
+============
-TODO/bugs In SILC Server
-========================
+ o SILC_PACKET_FLAG_ACK support. Implement ACK packet and packet payload
+ to silcpacket.c.
- o Configuration file additions:
+ o All payload encoding routines should take SilcStack as argument.
- o Add version handling, to allow, disallow certain versions to
- connect.
+ o Remove SilcCommandCb from silccommand.h.
- 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 All payload test routines into lib/silccore/tests/.
- o Add hashed passwords to config file.
- o Add rehashing support.
+lib/silcclient, The Client Library
+==================================
- 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 Giving WHOIS for nick that doesn't exist should remove any same
+ named entries from the client cache.
- 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 peer-to-peer private messages
- 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 Private message key request notification to application. See XXX in
+ client_prvmsg.c.
- o Backup router related issues
+ o in JOIN notify handle resolving that timedout. Currently the user is
+ never joined the channel if this happens. What to do if message is
+ received from user that hasn't been resolved/joined?
- o Channel user mode changes are notified unnecessarely when
- switching to backup router on router crash.
+ o Message ACKing support.
- o Lots of statistics updating is missing around the server.
+ o in /cmode and /cumode with +r, maybe the public key and private key
+ could be just some "string", which would then match to "string.pub" and
+ "string.prv".
- 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 If the SILC Events (see below) are implemented, perhaps client library
+ should provide events so that application developer has a choice of
+ developing the SILC app with callbacks or with events.
-TODO/bugs In SILC Libraries
-===========================
+Runtime library, lib/silcutil/
+==============================
+
+ o Fix universal time decoding (doesn't accept all formats) in silctime.c.
+
+ o Add functions to manipulate environment variables. (***DONE)
+
+ o Add functions to loading shared/dynamic object symbols (replaces the
+ SIM library (lib/silcsim) and introduces generic library). Add this
+ to lib/silcutil/silcdll.[ch]. (***TESTING NEEDED WIN32, TODO Symbian)
+
+ o Add directory opening/traversing functions
+
+ o silc_getopt routines
+
+ o The SILC Event signals. Asynchronous events that can be created,
+ connected to and signalled. Either own event routines or glued into
+ SilcSchedule:
+
+ SilcTask silc_schedule_task_add_event(SilcSchedule schedule,
+ const char *event, ...);
+ SilcBool silc_schedule_event_connect(SilcSchedule schedule,
+ const char *event,
+ SilcTaskCallback event_callback,
+ void *context);
+ SilcBool silc_schedule_event_signal(SilcSchedule schedule,
+ const char *event, ...);
+
+ Example:
+ silc_schedule_task_add_event(schedule, "connected",
+ SILC_PARAM_UI32_INT,
+ SILC_PARAM_BUFFER,
+ SILC_PARAM_END);
+ silc_schedule_event_connect(schedule, "connected", connected_cb, ctx);
+ silc_schedule_event_signal(schedule, "connected", integer, buf,
+ SILC_PARAM_END);
+ SILC_TASK_CALLBACK(connected_cb)
+ {
+ FooCtx ctx = context;
+ va_list args;
+ SilcUInt32 integer;
+ SilcBuffer buf;
+
+ va_start(args, context);
+ integer = va_arg(args, SilcUInt32);
+ buf = va_arg(args, SilcBuffer);
+ va_end(args);
+ ...
+ }
+
+ Problems: Events would be SilcSchedule specific, and would not work on
+ multi-thread/multi-scheduler system. The events should be copyable
+ between schedulers. Another problem is the signal delivery. Do we
+ deliver them synchronously possibly from any thread to any other thread
+ or do we deliver them through the target schedulers. If we use the
+ schedulers then signalling would be asynchronous (data must be
+ duplicated and later freed) which is not very nice.
+
+ o If the event signals are added, the SILC_PARAM_* stuff needs to be
+ moved from silcbuffmt.h to silctypes.h or something similar.
+
+ o In case the SILC Events are done we shall create a new concept of
+ parent and child SilcSchedule's. When new SilcSchedule is created a
+ parent can be associated to it. This association could be done either
+ directly by the parent or by any other children. This way the signals
+ would in effect be global and would reach all children schedulers.
+
+ This relationship would be associative only. The schedulers are still
+ independent and run independently from each other. All schedulers
+ would be linked and could be accessed from any of the schedulers.
+ It should be possible to retrieve the parent and enumate all children
+ from any of the schedulers.
+
+ SilcSchedule silc_schedule_init(int max_tasks, void *app_context,
+ SilcSchedule parent);
+ SilcSchedule silc_schedule_get_parent(SilcSchedule schedule);
+
+ o Additional scheduler changes: optimize silc_schedule_wakeup. Wakeup
+ only if the scheduler is actually waiting something. If it is
+ delivering tasks wakeup is not needed.
+
+ o Structured log messages to Log API. Allows machine readable log
+ messages. Would allow sending of any kind of data in a log message.
+
+ o Base64 to an own API
+
+ o Timer API
+
+ 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 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 silc_stringprep to non-allocating version.
- o Rewrite the lib/silcsim/silcsim.h. The SilcSimContext should be
- private and silc_sim_alloc should take necessary arguments.
+ o silc_hash_table_replace -> silc_hash_table_set. Retain support for
+ silc_hash_table_replace as macro. (***DONE)
- o SILC RNG does not implement random seed files, and they should be
- implemented.
+ o SilcStack aware SilcHashTable. (***DONE)
- 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.
+ o SilcStack aware SilcDList. (***DONE)
+ o Thread pool API. Add this to lib/silcutil/silcthread.[ch]. (***DONE)
-TODO in Toolkit Documentation
-=============================
+ o Fast mutex implementation. Fast rwlock implementation. Mutex and
+ rwlock implementation using atomic operations.
-Stuff that needs to be done in order to complete the Tooolkit Reference
-Manual.
+ o Compression routines are missing. The protocol supports packet
+ compression thus it must be implemented. SILC Zip API must be
+ defined.
+
+ o Add new functions to SilcStack API in lib/silcutil/silcstack.[ch]. Add
+ silc_stack_[set|get]_alignment. It defines the default alignment used
+ when allocating memory from stack. It can be used to specify special
+ alignments too when needed (such as for hardware devices like crypto
+ accelerators). Move also the low level silc_stack_malloc and
+ silc_stack_realloc from silcstack_i.h to silcstack.h. Remove the
+ _ua unaligned memory allocation routines. Remove unaligned memory
+ allocation possibility. (***DONE)
+
+ o Add '%@' format to silc_snprintf functions. It marks for external
+ rendering function of following type:
+
+ /* Snprintf rendering function. The `data' is rendered into a string
+ and allocated string is returned. If NULL is returned the
+ rendering is skipped and ignored. If the returned string does
+ not fit to the destination buffer it may be truncated. */
+ typedef char *(*SilcSnprintfRender)(void *data);
+
+ It can work like following:
+
+ char *id_renderer(void *data)
+ {
+ char tmp[32];
+ id_to_str(tmp, sizeof(tmp), (SilcID *)data);
+ return strdup(tmp);
+ }
+
+ silc_snprintf(buf, sizeof(buf), "Client ID %@", id_renderer, client_id);
- o Lots of ROBOdoc header formatting is undone in lib/silcutil, and
- lib/silccrypt.
+ (o Generic SilcStatus or SilcResult that includes all possible status and
+ error conditions, including those of SILC protocol. Though, the SILC
+ protocol related status (currently in silcstatus.h) cannot be in
+ runtime library) maybe
- 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 SILC specific socket creation/closing routines to silcnet.h, wrappers
+ to all send(), recv(), sendto() etc. Bad thing is that we'd have to
+ define all socket options, sockaddrs, etc.) maybe
- o Write "Platform Implementations" document to describe what platforms
- Toolkit support, what has been implemented, what has not been, what
- wors differently etc.
+ (o mmap) maybe
-TODO in SILC Protocol
+lib/silcutil/symbian/
=====================
-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 Something needs to be thought to the logging globals as well,
+ like silc_debug etc. They won't work on EPOC. Perhaps logging
+ and debugging is to be disabled on EPOC. The logging currently works
+ by it cannot be controlled, same with debugging.
+
+
+SFTP Library, lib/silcsftp/
+===========================
+
+ o Read prefetch (read-ahead, reading ahead of time). Maybe if this can
+ be done easily.
+
+
+SKR Library, lib/silcskr/
+=========================
+
+ o Add fingerprint as search constraint.
-A rough list of stuff that is going to be done to SILC after 1.0 or at
-least could be done.
+ o Add OpenPGP support. Adding, removing, fetching PGP keys. (Keyring
+ support?)
+
+ o Add support for importing public keys from a directory and/or from a
+ file. Add support for exporting the repository (different formats for
+ different key types?).
+
+ o Change the entire silc_skr_find API. Remove SilcSKRFind and just simply
+ add the find constraints as variable argument list to silc_skr_find, eg:
+
+ silc_skr_find(skr, schedule, callback, context,
+ SILC_SKR_FIND_PUBLIC_KEY, public_key,
+ SILC_SKR_FIND_COUNTRY, "FI",
+ SILC_SKR_FIND_USAGE, SILC_SKR_USAGE_AUTH,
+ SILC_SKR_FIND_END);
+
+ NULL argument would be ignored and skipped.
+
+ o Add OR logical rule in addition of the current default AND, eg:
+
+ // Found key(s) MUST have this public key AND this country.
+ silc_skr_find(skr, schedule, callback, context,
+ SILC_SKR_FIND_RULE_AND,
+ SILC_SKR_FIND_PUBLIC_KEY, public_key,
+ SILC_SKR_FIND_COUNTRY, "FI",
+ SILC_SKR_FIND_END);
+
+ // Found key(s) MUST have this public key OR this key context
+ silc_skr_find(skr, schedule, callback, context,
+ SILC_SKR_FIND_RULE_OR,
+ SILC_SKR_FIND_PUBLIC_KEY, public_key,
+ SILC_SKR_FIND_CONTEXT, key_context,
+ SILC_SKR_FIND_END);
+
+ o SilcStack to SKR API.
+
+
+Crypto Library, lib/silccrypt/
+==============================
+
+ o SilcStack to APIs.
+
+ o Add fingerprint to SilcSILCPublicKey and retrieval to silcpk.h, and
+ possibly to silcpkcs.h.
+
+ /* Return fingerprint of the `public_key'. Returns also the algorithm
+ that has been used to make the fingerprint. */
+ const unsigned char *
+ silc_pkcs_get_fingerprint(SilcPublicKey public_key,
+ const char **hash_algorithm,
+ SilcUInt32 *fingerprint_len);
+
+ o Change SILC PKCS API to asynchronous, so that accelerators can be used.
+ All PKCS routines should now take callbacks as argument and they should
+ be delivered to SilcPKCSObject and SilcPKCSAlgorithm too.
+
+ /* Signature computation callback */
+ typedef void (*SilcPKCSSignCb)(SilcBool success,
+ const unsigned char *signature,
+ SilcUInt32 signature_len,
+ void *context);
+
+ /* Signature verification callback */
+ typedef void (*SilcPKCSVerifyCb)(SilcBool success, void *context);
+
+ /* Encryption callback */
+ typedef void (*SilcPKCSEncryptCb)(SilcBool success,
+ const unsigned char *encrypted,
+ SilcUInt32 encrypted_len,
+ void *context);
+
+ /* Decryption callback */
+ typedef void (*SilcPKCSDecryptCb)(SilcBool success,
+ const unsigned char *decrypted,
+ SilcUInt32 decrypted_len,
+ void *context);
+
+ Either add new _async functions or add the callbacks to existing API
+ and if the callback is NULL then the API is not async and if provided
+ it may be async. For example;
+
+ SilcBool silc_pkcs_sign(SilcPrivateKey private_key,
+ unsigned char *src, SilcUInt32 src_len,
+ unsigned char *dst, SilcUInt32 dst_size,
+ SilcUInt32 *dst_len,
+ SilcBool compute_hash, SilcHash hash,
+ SilcPKCSSignCb async_sign,
+ void *async_sign_context);
+
+ (if this is done then there's no reason why the buffers in the
+ callbacks cannot be the ones user gives here) or allow only async:
+
+ SilcBool silc_pkcs_sign(SilcPrivateKey private_key,
+ unsigned char *src, SilcUInt32 src_len,
+ SilcBool compute_hash, SilcHash hash,
+ SilcPKCSSignCb async_sign,
+ void *async_sign_context);
+
+ or add new:
+
+ SilcBool silc_pkcs_sign_async(SilcPrivateKey private_key,
+ unsigned char *src, SilcUInt32 src_len,
+ SilcBool compute_hash, SilcHash hash,
+ SilcPKCSSignCb async_sign,
+ void *async_sign_context);
+
+ o Change PKCS Algorithm API to take SilcPKCSAlgorithm as argument to
+ encrypt, decrypt, sign and verify functions. We may need to for exmaple
+ check the alg->hash, supported hash functions. Maybe deliver it also
+ to all other functions in SilcPKCSAlgorithm to be consistent.
+
+ o Add DSS support. Take implementation from Tom or make it yourself.
o Implement the defined SilcDH API. The definition is in
- lib/silccrypt/silcdh.h.
+ lib/silccrypt/silcdh.h. Make sure it is asynchronous so that it can
+ be accelerated. Also take into account that it could use elliptic
+ curves.
+
+ o ECDSA and ECDH
+
+ o All cipher, hash, hmac etc. allocation routines should take their name
+ in as const char * not const unsigned char *.
+
+
+SILC Accelerator Library
+========================
+
+ o SILC Accelerator API. Provides generic way to use different kind of
+ accelerators. Basically implements SILC PKCS API so that SilcPublicKey
+ and SilcPrivateKey can be used but they call the accelerators.
+
+ Something in the lines of (preliminary):
+
+ /* Register accelerator to system. Initializes the accelerator. */
+ Varargs are optional accelerator specific init parameteres. */
+ SilcBool silc_acc_register(SilcAccelerator acc, ...);
+
+ silc_acc_register(softacc, "min_threads", 2, "max_threads", 16, NULL);
+
+ /* Unregister accelerator. Uninitializes the accelerator. */
+ SilcBool silc_acc_unregister(const SilcAccelerator acc);
+
+ /* Return list of the registered accelerators */
+ SilcDList silc_acc_get_supported(void);
+
+ /* Find existing accelerator. `name' is accelerator's name. */
+ SilcAccelerator silc_acc_find(const char *name);
+
+ /* Return accelerator's name */
+ const char *silc_acc_get_name(SilcAccelerator acc);
+
+ /* Accelerate `public_key'. Return accelerated public key. */
+ SilcPublicKey silc_acc_public_key(SilcAccelerator acc,
+ SilcPublicKey public_key);
+
+ /* Accelerate `private_key'. Returns accelerated private key. */
+ SilcPrivateKey silc_acc_private_key(SilcAccelerator acc,
+ SilcPrivateKey private_key);
+
+ /* Return the underlaying public key */
+ SilcPublicKey silc_acc_get_public_key(SilcAccelerator acc,
+ SilcPublicKey public_key);
+
+ /* Return the underlaying private key */
+ SilcPrivateKey silc_acc_get_private_key(SilcAccelerator acc,
+ SilcPrivateKey private_key);
+
+ typedef struct SilcAcceleratorObject {
+ const char *name; /* Accelerator's name */
+ SilcBool (*init)(va_list va); /* Initialize accelerator */
+ SilcBool (*uninit)(void); /* Uninitialize accelerator */
+ const SilcPKCSAlgorithm *pkcs; /* Accelerated PKCS algorithms */
+ const SilcDHObject *dh; /* Accelerated Diffie-Hellmans */
+ const SilcCipherObject *cipher; /* Accelerated ciphers */
+ const SilcHashObject *hash; /* Accelerated hashes */
+ const SilcHmacObject *hmac; /* Accelerated HMACs */
+ const SilcRngObject *rng; /* Accelerated RNG's */
+ } *SilcAccelerator, SilcAcceleratorStruct;
+
+ Allows accelerator to have multiple accelerators (cipher, hash etc)
+ and multiple different algorithms and implementations (SHA-1, SHA-256 etc).
+
+ SilcPublicKey->SilcSILCPublicKey->RsaPublicKey accelerated as:
+ SilcPublicKey->SilcAcceleratorPublicKey->SilcSoftAccPublicKey->
+ SilcPublicKey->SilcSILCPublicKey->RsaPublicKey
+
+ silc_acc_public_key creates SilcPublicKey and SilcAcceleratorPublicKey
+ and acc->pkcs->import_public_key creates SilcSoftAccPublicKey.
- 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.
+ o Implement software accelerator. It is a thread pool system where the
+ public key and private key operations are executed in threads.
- 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.
+ const struct SilcAcceleratorObject softacc =
+ {
+ "softacc", softacc_init, softacc_uninit,
+ softacc_pkcs, NULL, NULL, NULL, NULL
+ }
- Other package that should be checked is the NSS's X509 library,
- which I like more over OpenSSL package.
+ /* Called from silc_acc_private_key */
+ int silc_softacc_import_private_key(void *key, SilcUInt32 key_len,
+ void **ret_private_key)
+ {
+ SilcSoftAccPrivateKey prv = silc_calloc(1, sizeof(*prv));
+ prv->pkcs = acc->pkcs;
+ prv->private_key = key;
+ *ret_private_key = prv;
+ }
- o SSH2 public keys support, allowing the use of SSH2 public keys in
- SILC.
+ (o Symmetric key cryptosystem acceleration? They are always sycnhronouos
+ even with hardware acceleration so the crypto API shouldn't require
+ changes.) maybe
+
+
+lib/silcmath
+============
+
+ o Import TFM. Talk to Tom to add the missing functions. Use TFM in
+ client and client library, but TMA in server, due to the significantly
+ increased memory consumption with TFM, and the rare need for public
+ key operations in server.
+
+ We want TFM's speed but not TFM's memory requirements. Talk to Tom
+ about making the TFM mp dynamic just as it is in LTM.
+
+ o The SILC MP API function must start returning indication of success
+ and failure of the operation.
+
+ o Do SilcStack support for silc_mp_init, silc_mp_init_size and other
+ any other MP function (including utility ones) that may allocate
+ memory.
+
+ o All utility functions should be made non-allocating ones.
+
+
+SILC XML Library, lib/silcxml/
+==============================
+
+ o SILC XML API (wrapper to expat). Look at the expat API and simplify
+ it. The SILC XML API should have at most 8-10 API functions. It should
+ be possible to create full XML parser with only one function. And, it
+ should be possible to have a function that is able to parse an entire
+ XML document. It should also have a parser function to be able to
+ parse a stream of XML data (SilcStream). It MUST NOT have operations
+ that require multiple function calls to be able to execute that one
+ operation (like creating parser).
+
+
+lib/silcske/silcske.[ch]
+========================
+
+ o Ratelimit to UDP/IP transport for incoming packets.
+
+
+lib/silcasn1
+============
+
+ o Negative integer encoding is missing, add it.
+
+ o SILC_ASN1_CHOICE should perhaps return an index what choice in the
+ choice list was found. Currently it is left for caller to figure out
+ which choice was found.
+
+ o SILC_ASN1_NULL in decoding should return SilcBool whether or not
+ the NULL was present. It's important when it's SILC_ASN1_OPTIONAL
+ and we need to know whether it was present or not.
+
+
+lib/silcpgp
+===========
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.
+lib/silcssh
+===========
- 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 SSH2 public key/private key support, allowing the use of SSH2 keys
+ in SILC. RFC 4716.
+
+
+lib/silcpkix
+============
+
+ o PKIX implementation
+
+
+apps/silcd
+==========
+
+ o Deprecate the old server. Write interface for the new lib/silcserver
+ server library. The interface should work on Unix/Linux systems.
+
+ o Consider deprecating also the old config file format and use XML
+ istead. This should require SILC XML API implementation first.
+
+ o The configuration must support dynamic router and server connections.
+ The silcd must work without specifying any servers or routers to
+ connect to.
+
+ o The configuration must support specifying whether the server is
+ SILC Server or SILC Router. This should not be deduced from the
+ configuration as it was in < 1.2.
+
+ o The configuration must support specifying the ciphers and hmacs and
+ their order so that user can specify which algorithms take preference.
+
+
+lib/silcserver
+==============
+
+ o Rewrite the entire server. Deprecate apps/silcd as the main server
+ implementation and create lib/silcserver/. It is a platform
+ independent server library. The apps/silcd will merely provide a
+ a simple interface for the library.
+
+ o Write the SILC Server library extensively using SILC FSM.
+
+ o Server library must support multiple networks. This means that one
+ server must be able to create multiple connections that each reach
+ different SILC network. This means also that all cache's etc. must
+ be either connection-specific or network-specific.
+
+ o Library must support dynamic router and server connections. This means
+ that connections are create only when they are needed, like when someone
+ says JOIN foo@foo.bar.com or WHOIS foobar@silcnet.org.
+
+ o Library must support server-to-server connections even though protocol
+ prohibits that. The responder of the connection should automatically
+ act as a router. The two servers create an own, isolated, SILC network.
+ To be used specifically with dynamic connections.
+
+ o Library must support multiple threads and must be entirely thread safe.
+
+ o Library must have support for SERVICE command.
+
+ o The server must be able to run behind NAT device. This means that
+ Server ID must be based on public IP instead of private IP.
+
+ o The following data must be in per-connection context: client id cache,
+ server id cache, channel id cache, all statistics must be
+ per-connection.
+
+ o The following data must be in per-thread context: command context
+ freelist/pool, pending commands, random number generator.
+
+ o Do inccoming packet processing in an own FSM thread in the
+ server-threads FSM. Same as in client library.
+
+ o Reference count all Silc*Entry structures.
+
+ Some issues that must be kept in mind from 1.0 and 1.1 silcd's:
+
+ 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 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.
+
+ 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.