the rationale behind switching away from SGML/Docbook is the following:
* SGML is hard to edit for humans
* the output is not much prettier
* the toolchain is not well supported and missing from the build
* the build is not hooked into anywhere, no automation
the reason why RST was chosen:
* it allows for a strong structure like Docbook
* the theme from Read The Docs is pretty
* it also supports mobile devices
* sphinx can easily output to PDF and ePUB formats
* RST is plaintext that can be easily edited and diff'd
* RST can be automatically built by ReadTheDocs and the toolchain is
readily available
* the output is also parsed by Github so documentation can be read
straight from GH
the reason why Markdown was not chosen:
* the current strong structure would be hard to replicate
* markdown is not standardized and output varies according to the
implementation
the docs were converted with Pandoc, using the following commands:
mkdir oper-guide
for source in sgml/oper-guide/*.sgml; do
pandoc --toc -s -f docbook -t rst $source -o oper-guide/$(basename $source .sgml).rst
done
cd oper-guide
sphinx-quickstart
git add *.rst make.bat conf.py
git add -f Makefile
git rm -r ../sgml
the [manpage][] says:
> unsigned int * cert_max
> Initially must hold the maximum number of certs. It will be updated
> with the number of certs available.
ratbox doesn't actually initialize that variable, so gnutls naturally
fails. i would also recommend considering dynamically allocating the
cert list to deal with that error in other ways than failing to
configured SSL completely in GnuTLS. the apache gnutls module has a
similar problem and came up with a [patch][] to do exactly this which
you may want to consider.
but since our cert chain is only (!) 5 certs long, our itched is
scratch by this particular patch.
[manpage]: https://manpages.debian.org/jessie/gnutls-doc/gnutls_x509_crt_list_import.3.en.html
[patch]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511573#35
This change modifies extb_channel to allow matching users in secret
channels, which prevents trivial ban evasion by setting the target
channel +s. Information leak due to this change is unlikely since the
attacker would have to know that the target channel exists, the name of
the channel (or guess it), have a specific user they wanted to know
whether was in the channel (and not know already), and the target user
would need to have something like autojoin-on-invite enabled (or any of
the other various ways hostname cloaking is attacked).
When a remote MODRESTART command is received, it will pass through the
ENCAP module. The ms_encap function is responsible for dispatching the
command handler and then the modules will eventually be reloaded.
However, if the ENCAP module is reloaded to a different address, the
stack now contains the address of a function that no longer exists.
Return immediately from the command handler and have the event loop
call the function responsible for reloading the modules instead.
Reported-by: mniip (Freenode)
When certificate validation fails, the certificate fingerprint won't be
calculated, resulting in an attempt to format NULL into a log line
showing the fingerprint. Instead, add a different error message for
missing fingerprint (i.e. validation failed).
Add REHASH SSLD (admins only) that starts new sslds and marks the
existing ones as inactive until all their clients disconnect.
Very useful whenever the SSL library has a vulnerability because
new connections can use a new version of the library without
disconnecting existing clients/servers.
Add STATS S (admins only) to list ssld processes, status, and client
count.
As well as leaking a connid and leaving the connection open,
these calls to free_client() leave the client in the unknown_list
causing check_unknowns_list() to crash when either ptr->data
(ptr being the freed client_p->localClient->tnode) is NULL or
when client_p->localClient is NULL.
Flag the client as an IO error so that we don't try to send it
any data (as this is not a normal plaintext connection).
This backports the code responsible for SPKI digests from release/4.
It also adjusts doc/reference.conf to note that SPKI digests are now
supported, and how to generate them. It does NOT backport the mkfingerprint
program -- the instructions in reference.conf are sufficient. I am ofcourse
open to anyone else backporting the program, but I don't see the need.
==00:00:01:09.081 1762== 48 bytes in 2 blocks are definitely lost in loss record 545 of 991
==00:00:01:09.081 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.081 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.081 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.081 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.081 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.081 1762== by 0x4E52AC3: init_cache (cache.c:67)
==00:00:01:09.081 1762== by 0x4E69530: charybdis_main (ircd.c:762)
==00:00:01:09.081 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 2,808 bytes in 117 blocks are definitely lost in loss record 960 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E5337A: load_help (cache.c:301)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 5,328 (5,304 direct, 24 indirect) bytes in 221 blocks are definitely lost in loss record 971 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E53278: load_help (cache.c:266)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==01:17:20:36.920 5966== 429 bytes in 3 blocks are possibly lost in loss record 899 of 1,020
==01:17:20:36.920 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.920 5966== by 0x4E73867: rb_strdup (rb_memory.h:70)
==01:17:20:36.920 5966== by 0x4E7674C: conf_set_connect_fingerprint (newconf.c:1421)
==01:17:20:36.920 5966== by 0x4E78D55: conf_call_set (newconf.c:2562)
==01:17:20:36.920 5966== by 0x4E6A33D: yyparse (ircd_parser.y:215)
==01:17:20:36.920 5966== by 0x4E7FFC7: read_conf (s_conf.c:834)
==01:17:20:36.920 5966== by 0x4E81718: read_conf_files (s_conf.c:1419)
==01:17:20:36.920 5966== by 0x4E69567: charybdis_main (ircd.c:775)
==01:17:20:36.920 5966== by 0x400815: main (main.c:8)
==01:17:20:36.919 5966== 280 bytes in 8 blocks are definitely lost in loss record 876 of 1,020
==01:17:20:36.919 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.919 5966== by 0x4E93F4F: rb_strdup (rb_memory.h:70)
==01:17:20:36.919 5966== by 0x4E95280: ssl_process_cipher_string (sslproc.c:476)
==01:17:20:36.919 5966== by 0x4E95540: ssl_process_cmd_recv (sslproc.c:561)
==01:17:20:36.919 5966== by 0x4E9582A: ssl_read_ctl (sslproc.c:632)
==01:17:20:36.919 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.919 5966== by 0x56C4EB5: rb_select (commio.c:2085)
==01:17:20:36.919 5966== by 0x56C7FD6: rb_lib_loop (rb_lib.c:228)
==01:17:20:36.919 5966== by 0x4E69987: charybdis_main (ircd.c:872)
==01:17:20:36.919 5966== by 0x400815: main (main.c:8)
==01:17:20:36.906 5966== 48 bytes in 1 blocks are definitely lost in loss record 544 of 1,020
==01:17:20:36.906 5966== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.906 5966== by 0x4E93F0C: rb_malloc (rb_memory.h:41)
==01:17:20:36.906 5966== by 0x4E961E8: start_zlib_session (sslproc.c:901)
==01:17:20:36.906 5966== by 0x4E86FAC: server_estab (s_serv.c:877)
==01:17:20:36.906 5966== by 0x13B2921A: mr_server (m_server.c:304)
==01:17:20:36.906 5966== by 0x4E7AF03: handle_command (parse.c:241)
==01:17:20:36.906 5966== by 0x4E7A96A: parse (parse.c:157)
==01:17:20:36.906 5966== by 0x4E7A3DC: client_dopacket (packet.c:354)
==01:17:20:36.906 5966== by 0x4E798D6: parse_client_queued (packet.c:98)
==01:17:20:36.906 5966== by 0x4E79FAC: read_packet (packet.c:282)
==01:17:20:36.906 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.906 5966== by 0x56C4EB5: rb_select (commio.c:2085)
The CHALLENGE functionality will set opername but not privset --
if an oper performs a WHOIS on someone currently half-way through
a challenge we will perform a NULL dereference.
Related to ircd-seven commit d7b05f7583babf6
