This fixes a compiler warning. The necessary fields of the struct sigevent
were initialized so there was no problem.
Submitted by: Aaron (via IRC)
Reviewed by: Attila
The last byte of balloc.c's block pointer could be changed from 10 or 13 to
0. On amd64, this is not possible. On i386, this is possible and usually
causes a crash soon.
When receiving bans from a bursting server, if kline_delay is set to 0
(the default), rb_event_addonce will be called to schedule an event for
0 seconds in the future. While this works fine for the fallback
rb_event_run function, the epoll implementation ends up scheduling a
timerfd for the event in the past, which is then never executed.
While fixing this, I also made rb_event_add and rb_event_addonce reject
attempts to add events scheduled for 0 seconds in the future; they're
instead rewritten to run 1 second in the future.
SSL_OP_NO_COMPRESSION was presumably added in an attempt to prevent
information leakage in a manner similar to recent attacks on HTTPS.
However, assuming that IRC is vulnerable to the same class of attacks is
incorrect: the behavior of the IRC protocol (a single long-running
connection) is not the same as that of HTTPS (multiple ephemeral
connections). HTTPS's use of ephemeral connections means that certain
assumptions can be made about the contents of the compression
algorithm's dictionaries and the content exchanged between the client
and server (e.g. the content being nearly the same for each connection),
which is not true for IRC. Additionally, they rely on the attacker being
able to coerce the client into creating many HTTPS connections (and
resending some secret token belonging to the user, along with
attacker-controlled data) each time, none of which is possible with IRC.
Lastly, since compression is no longer performed, this option will
result in leaking the lengths of messages transmitted to and from the
client. This option does reduce CPU utilization on Charybdis servers but
also increases bandwidth consumed.
The C standard does not allow constructing pointers beyond one past the end
of an array. Therefore, if size is an unsigned type (size_t), then
buf + size is never less than buf.
Clang on 32-bit took advantage of the undefined behaviour, causing
segfaults.
Lightly tested.
Note that these are not available in old versions of OpenSSL (like FreeBSD
9.x base OpenSSL), so allow them to be missing.
A side effect may be slightly higher CPU consumption and network traffic.
Without a session id context and if client certificates are used, OpenSSL
fails the handshake if an attempt is made to reuse an old session. Various
clients could not reconnect after a disconnection because of this.
See https://bugzilla.mozilla.org/show_bug.cgi?id=858394#c34 for a bug
report.
rb_crypt() was generating different SHA256 ($5$) hashes than glibc,
making hashes generated with charybdis unusable in ratbox and other
software, and vice versa.
Note that you must have options ACCEPT_FILTER_DATA in your kernel
configuration or load the accf_data kernel module. The functionality is
not in the GENERIC kernel.
This allows for some further hardening against synflooding and connection flooding
where no data is actually sent, as the kernel will simply ignore those connections
(well, as far as the ircd is concerned anyway).
Add two mechanism for avoiding name-collisions in a system-wide
installation of charybdis. The ssld and bandb daemons, intended to be
directly used by ircd and not the user, install into libexec when
--enable-fhs-paths is set. For binaries which are meant to be in PATH
(bindir), such as ircd and viconf, there is now an option
--with-program-prefix=progprefix inspired by automake. If the user
specifies --with-program-prefix=charybdis, the ircd binary is named
charybdisircd when installed.
Add support for saving the pidfile to a rundir and storing the ban
database in localstatedir instead of in sysconfdir. This is, again,
conditional on --enable-fhs-paths.
Fix(?) genssl.sh to always write created SSL key/certificate/dh
parameters to the sysconfdir specified during ./configure. The
previous behavior was to assume that the user ran genssl.sh after
ensuring that his current working directory was either sysconfdir or a
sibling directory of sysconfdir.
