For outgoing connections, we use 2048 (DH_BITS) since commit 49b2d0e. This patch enables ngIRCd to accept incoming connections from other servers and clients that use at least 1024 bits (and no longer requires 2048 for incoming connections, too). Patch proposed by Florian Westphal.

Bob Jenkins published a newer hash function in May 2006, it has better distribution. See http://burtleburtle.net/bob/hash/doobs.html for lengthy comparisions.

* MorePrivacy: New configuration opion "MorePrivacy" to "censor" some user information

this patch contains: * Fix for Conf_CloakUserToNick to make it conceal user details * Adds MorePrivacy-feature MorePrivacy censors some user information from being reported by the server. Signon time and idle time is censored. Part and quit messages are made to look the same. WHOWAS requests are silently dropped. All of this is useful if one wish to conceal users that access the ngircd servers from TOR or I2P.

* ScrubCTCP: Add documentation for "ScrubCTCP" configuration option New option to scrub incoming CTCP commands

* newconfig: sample-ngircd.conf: "SyslogFacility" should be commented out Move SSL-related configuration variables to new [SSL] section CheckFileReadable(): only check when a filename is given ... PAM: make clear which "Password" config option is ignored Really remove [Features] in our manual pages INSTALL: document changed location of configuration variables Update sample config file and manual page for new config structure Testsuite: update configuration files for new config file format Display configuration errors more prominent on "--configtest" conf.c: code cleanup Check for redability of SSL-related files like for MOTD file Restructure ngIRCd configuration, introduce [Limits] and [Options]

This patch makes it possible to scrub incomming CTCP commands from other servers and clients alike. The ngircd oper can enable it from the config file, by adding "ScrubCTCP = yes" under [OPTIONS]. It is default off. CTCP can be used to profile IRC users (get user clients name and version, and also their IP addresses). This is not something we like to happen when user pseudonymity/secrecy is important. The server silently drops incomming CTCP requests from both other servers and from users. The server that scrubs CTCP will not forward the CTCP requests to other servers in the network either, which can spell trouble if not every oper knows about the CTCP-scrubbing. Scrubbing CTCP commands also means that it is not possible to send files between users. There is one exception to the CTCP scrubbing performed: ACTION ("/me commands") requests are not scrubbed. ACTION is not dangerous to users (unless they use OTR, which does not encrypt CTCP requests) and most users would be confused if they were just dropped. A CTCP request looks like this: ctcp_char, COMMAND, arg0, arg1, arg2, .. argN, ctcp_char ctcp_char is 0x01. (just like bold is 0x02 and color is 0x03.) They are sent as part of a message and can be delivered to channels and users alike.