ngIRCd Release 26~rc1

Update config.guess and config.sub to recent versions - config.guess: 2020-04-26 - config.sub: 2020-05-04 And set both scripts +x, they are executable.

Update NEWS and ChangeLog files

Add missing authors to AUTHORS, tweak ".mailmap" file

Tweak & update doc/HowToRelease.txt a bit ...

Allow more characters per line in MOTD and help text files Change the line buffer in the Read_TextFile() function from 127 to COMMAND_LEN (=512) bytes. Lines can't even get that long, because they have to be prefixed before being sent to the client, so this is a sane maximum. This allows for even more "fancy" and "wider" MOTDs :-) Closes #271.

Show allowed channel types in ISUPPORT(005) numeric only Don't show the static list of all possibly available channel types ... Closes #273.

Platforms.txt: Add x86_64/apple/darwin19.0.0 - Add x86_64/apple/darwin19.0.0 (Apple clang 11.0)

Update Platforms.txt - Update powerpc/apple/darwin8.11.0 (gcc 4.0.1) - Add mips/sgi/irix6.5 (SGI C compiler) - Add mipsel/unknown/netbsd8.0 (gcc 5.5.0) Thanks to Götz Hoffart <goetz@hoffart.de>!

SSL test server: Use port 6790, like "test server #2" Don't use the "standard" IRC SSL port 6697, as this easily collides with real (ng)IRCd instances running on the same machine. And by reusing port 6790, which is already used by the "test server #2", we don't need any other port than the test suite already uses.

Git: Ignore generated files of SSL tests

Merge pull request #269 from hillu/gnutls-reload-cert Add support for GnuTLS certificate reload. Thanks a lot, Hilko Bengen!

Update Client_SetHostname() to not use strpbrk() Not sure about the portability of strpbrk() in really ancient OS, and this was the only place where it became used recently in ngIRCd ... So let's play it safe! ;-)

updating testsuite to support ssl-tests

Allow hostmask cloaking when rDNS is disabled

GnuTLS: Eliminate memory leaks for DH parameters, priorities cache The DH parameters reference has to be stored next to the x509_cred which holds a reference to it.

Don't wait for the network when read buffers possibly hold commands There is no point in waiting up to one second for the network receiving new data when there is still a read buffer holding at least one command; we shouldn't waste time but handle it immediately!

Add support for GnuTLS certificate reload This requires keeping track of currently active certificates, so those are stored separately, along with a reference counter, and discarded when they are no longer in use.

Handle commands in the read buffer before reading more data If there are more bytes in the read buffer already than a single valid IRC command can get long (513 bytes, COMMAND_LEN), wait for this/those command(s) to be handled first and don't try to read even more data from the network (which most probably would overflow the read buffer of this connection soon).

Update documentation to reflect "[Channel]->Modes" changes No longer mention "[Channel]->Key" and "[Channel]->MaxUsers".

Read_Request(): Clean up code and add some more comments No functional changes.

Convert INSTALL and README files to Markdown This requires some changes to the build system, for example to comply with the expectations of the GNU autoconf/automake tools ...

Revert "Increase read buffer size for server connections" This reverts commit c6e3c13f27744971fcb1d2de4e561d3bcdaa5aed. This sounded like the right approach at first, but I'm not that sure that it really makes sense to have different sizes of read buffers: the per-connection read buffer only needs to keep data that is needed to parse one full command, be it plain text, encrypted and/or compressed. Then ngIRCd should handle this one command, move leftover data to the beginning of the buffer and read the next chunk from the network that is missing to get the next complete command (512 bytes at max). So I revert this for now and try to fix the logic in Read_Request(), which is broken nevertheless, as it results in servers becoming disconnected during "server burst" when "big" lists are transferred.

Add deprecation warnings for "Key" and "MaxUsers" in [Channel]

Correctly use Config_Error() instead of Log() in Read_Config() The name of the Config_Error() function is misleading: it is not only used to show configuraton errors, but all messages shown during normal operation as well as for "config testing": it takes care of the correct formatting of the messages (syslog, forground logging, config testing). This fixes commit bb1d014abad8.