[sr-dev] some observations on kamailio

- suid code: I notice that the daemon drops perms before loading the TLS private key file. It would be better to load the file first, so that only root needs read access to the private key - does the current TLS module architecture support that? - comments on 1024 bit RSA: the docs recommend not to use key sizes > 1024. http://kamailio.org/docs/modules/devel/modules/tls.html#certificate However, this seems to be the opposite of what virtually all security experts are now saying: most people believe 2048 is bare minimum and 4096 is the better choice for new deployments where no legacy clients might exist - also related the above issue, the doc says `bytes', I think it means to say 1024 bits - is there a compelling reason to use hard-coded IP addresses for SIP config files? For all my apps that have special IP requirements, I always create dedicated DNS names for each of my virtual/interface IPs. Then I like to put that dedicated DNS name (rather than just the hostname) in the config file. The listen= directive in kamailio.cfg doesn't appear to support this though. - DB setup - I notice that the kamdbctl script expects to make databases and make tables in one step. It is not unusual for a security-conscious admin to deny DBA access from app servers (e.g. the server where kamailio is installed). Maybe kamdbctl needs an option to skip DB creation, and just do table creation? I found I could achieve this just by editing: /usr/lib/kamailio/kamctl/kamdbctl.mysql and commenting the `exit 1' line in this code: if [ $? -ne 0 ] ; then merr "Creating core database and grant privileges failed!" #exit 1 fi - an alternative solution might be to modify kamdbctl so that it just connects in read-only mode to make any checks, writes all the DDL statements to a file that the SIP admin can give to their DBA (or even if it is the same person, they may have a standalone MySQL box, and they don't want to install all of kamdbctl on that box)