Set current_capmask and then use it, instead of referencing target_p->localClient->caps again.
This makes the purpose of current_capmask a bit clearer.
strlcpy should be called with the size of the destination buffer, not
the length of the source string.
When the source is an empty string, the destination buffer isn't
written at all, resulting in it trying to output uninitialised data.
This could also cause a buffer overflow on very long invalid config
lines.
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.
Also, in this version of the IRCd, the module restarting functionality
was located in a function that is itself located in a module, so things
will also go badly if that module is reloaded to a different address,
too.
Return immediately from the command handler and have the event loop
call the function responsible for reloading the modules instead.
c.f. release/3.5 commit db05a36210
Reported-by: mniip (Freenode)
When both account-tag and server-time are present but the client
doesn't have the first (i == 0) of these enabled. They will get
an erroneous ';' after the '@'.
Track whether or not there are tags present, and use this to
determine whether to add the ';' or not. Also remove the extra
function that loops over all of the tags by using this flag to
handle the case where there are no tags being written.
Build the same message but send it to the local client first,
so that the echo-message capability works. But don't do it when
sending a message to yourself.
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).
==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)
[ircd/match.c:316]: (error) Shifting a negative value is undefined behaviour
[librb/src/patricia.c:55]: (error) Shifting a negative value is undefined behaviour
[modules/m_alias.c:64]: (portability) '(void*)message' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[modules/m_time.c:111]: (warning) %u in format string (no. 9) requires 'unsigned int' but the argument type is 'signed int'.
[modules/m_time.c:111]: (warning) %u in format string (no. 10) requires 'unsigned int' but the argument type is 'signed int'.
[librb/src/dictionary.c:819]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[librb/src/radixtree.c:1080]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[ircd/s_user.c:351] -> [ircd/s_user.c:357]: (warning) Either the condition '0!=source_p' is redundant or there is possible null pointer dereference: source_p.
[extensions/ip_cloaking_3.0.c:109]: (warning, inconclusive) The buffer 'buf' may not be null-terminated after the call to strncpy().
[ircd/chmode.c:256]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_help.c:100]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_knock.c:169]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:628]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:727]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:601]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:704]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:739]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:763]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:768]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:774]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:781]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:786]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:791]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:804]: (style) Clarify calculation precedence for '&' and '?'.
[ircd/wsproc.c:372]: (style) Unused variable: len
[modules/core/m_modules.c:382]: (style) Unused variable: i
[modules/m_stats.c:741]: (style) Unused variable: amsg
[ircd/authproc.c:390]: (style) Unused variable: iter
[ircd/authproc.c:391]: (style) Unused variable: client_p
Links that are 'no-export' are not distributed to the rest of the IRC network (including local peers).
This provides a core primitive for 'anycasting' services (but the actual issue of synchronizing data in
a services package is left to the authors of the services package).
On FreeBSD 4.8, fork(2) doesn't actually behave like fork(2).
Namely, kqueue(2) descriptors are not inherited by the child.
IOW, we can't fork(2) after we get the kqueue(2) descriptor.
So we'll just have to rely on people to actually read the
server log file if they want to understand why their server
is dying during startup.
This will allow service process monitoring to recognise the difference
between a shutdown and an error of a -foreground ircd, because only
/DIE (or SIGINT) will exit with return code 0.
It's useful to allow authd to run in parallel with ssl negotiation,
but if the ssld connection has plaintext data ready for reading
there's a race condition between authd calling read_packet() and
ssl_process_certfp() storing the certificate fingerprint. This
scenario would be bad for a server connecting because fingerprint
verification will fail.
Allow either operation to complete first, but wait until
ssl_process_open_fd() calls the ssl open callback before calling
read_packet().
Don't use the librb callback type as we're always passing client_p.
Provide a return value so that the connect handler can exit_client()
and the accept handler can opt to use the default dead handler.
There's no need to pass information around that sslproc already has access
to, so use ServerInfo directly. Remove the extra NULL checks as these are
already performed before setting ircd_ssl_ok = true.
Fix the server connection configuration so that it can simultaneously
handle a hostname/IPv4/IPv6 for connecting and a hostname/IPv4/IPv6
for binding. Maintains backwards compatibility for matching a hostname
with a mask.
Multiple host/vhost entries can be specified and the last value for
each address family is stored. Hostnames that resolve automatically
overwrite the IP address.
Server connections can now be made to either IPv4 or IPv6 at random
as well as preferring a specific address family.
These operate on the SubjectPublicKeyInfo of the certificate, which does
change unless the private key is changed. This allows the fingerprint to
stay constant even if the certificate is reissued.
(The same fingerprint is also used by DANE)
This also lays the groundwork for the netjoin batch type, but that isn't
implemented yet. I don't like how some of this is implemented but it'll
have to do for now...
Compile tested, needs more testing.
It's a bit of a hack, but better than before. Rather than rehashing
(which could get us into an endless loop), we now segregate the
configuration phase (creating entries ircd-side in case we restart authd
later) and sending phases (when configure_authd() is called). Since we
have to call configure_authd() no matter what (to send timeouts etc.)
and we have to send this data to configure authd anyway, and sending
duplicate data is bad, this is the only way I can think of for now.
It seems to come from an era where long long didn't exist and 64-bit
machines weren't common. 32-bit machines are still common but I can't
imagine this will have much performance impact there.
This "fixes" #179 in title only, but see comments within.
Clean up spaces/tabs mixing mess (bleh), add some defaults for authd
stuff, and get rid of CHARYBDIS_SOMAXCONN (just define SOMAXCONN if it's
available...).
There's no reason to really have these in the main ircd anymore, static
modules are dead and aren't coming back.
To ensure people don't do something hopelessly retarded, this is a core
module.
Provider ID's are now assigned dynamically at load-time. To accomodate
this, there is now a lookup system for finding providers by name (all
providers have names as well).
