https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/?h=amdj%2Ffix-buildsys-headers 2026-05-14T23:51:12Z 2026-05-14T23:51:12Z Aaron Jones 2026-05-04T08:46:15Z urn:sha1:2f62754caef32904f589a54edd9856c592b6164e - Unconditionally require stdbool.h in IRCd We are a C99 project anyway (configure.ac and meson.build both require a C99 compiler), so this header will always be present This removes the awful hack defining bool, true, and false in its absense, which was creating build errors when using meson, because meson.build did not set the HAVE_STDBOOL_H macro - Modernise definition of alloca(3) according to GNU guidance This was in both librb and IRCd, while it only needs to be in the former - Fix missing endianness check in librb/meson.build IRCd and librb both use the WORDS_BIGENDIAN macro, which was only being set by their configure.ac (with the AC_C_BIGENDIAN M4 macro) Since IRCd's stdinc.h includes librb's rb_lib.h, which then includes librb's librb-config.h, which would have the macro defined there, we only need to check for it in librb, so we can remove the endianness check from IRCd's configure.ac and don't need to add it to IRCd's meson.build - Use __has_attribute to detect whether compiler attributes are available This is supported by gcc (5+), clang (2.9+), and ICC (17+) - Add a __noreturn macro for __attribute__((__noreturn__)) and adjust the codebase to use that - Remove inclusion of headers that are only used by librb - Remove inclusion of headers that are included in rb_lib.h because stdinc.h includes rb_lib.h anyway - Remove the checks for headers and functions from the IRCd configure.ac and meson.build that are only used by librb - Alphabetise checks for headers and functions (by the name of the macro they define) in the meson.build files - Use check_header() instead of has_header() in meson to see if it is actually possible to compile code using the header - Remove dead code using srand48(3) which has never been compiled because neither build system has ever set the HAVE_SRAND48 macro and the surrounding code makes no use of this libc RNG - Remove the TLS defines from IRCd's meson.build because librb's meson.build already defines them and IRCd pulls those in 2026-04-29T16:12:34Z Ryan Schmidt 2026-04-11T04:05:08Z urn:sha1:eacc3388cd75060a1ece9209c24c85bc20b65ff7 When loading a module that modifies config (add/remove conf items or top conf sections), we now queue a rehash operation so that new config can be immediately applied. A new rb_defer_once() function was added to deduplicate these rehash requests so that at most one rehash will occur regardless of how many modules change conf. 2026-04-29T16:12:04Z Ryan Schmidt 2026-01-28T02:48:41Z urn:sha1:13969e96c9993892924b61f4b98d25626b4f1e2f This extension module provides a new usermode (+q) and two commands that allow opers to set/unset that mode. The mode can be set either via ircd.conf (general::default_umodes or auth::umodes) or via the QUARANTINE command. When using the command, a reason is required which will be broadcast to all other opers via the snote. The quarantine will be automatically removed if the target opers up or logs into a services account, and opers and logged in users cannot be quarantined. The UNQUARNTINE command may additionally be used to remove the quarantine status from a user. Users cannot otherwise set or remove this usermode from themselves. The QUARANTINE and UNQUARANTINE commands require a new priv oper:quarantine. To support this, a new account_change hook was added to m_services and m_signon. This hook is fired whenever a user's services account changes (via logging in or logging out) from the SVSLOGIN, SIGNON, LOGIN, or SU services commands. It is **not** fired for SVSLOGIN on unknown (pre-registration) users. Documentation was updated for the new usermode, hook, and commands. Usermode help was alphabetized for consistency, a missing entry for helpops was added, and cloaking was moved to +x (since all modern cloaking modules use that mode instead) since I was touching the file anyway. 2026-04-09T19:33:53Z Aaron Jones 2026-04-05T17:48:47Z urn:sha1:54286cf59235c8688104ee20d4e1d74fe8934317 2026-04-09T17:45:27Z Ryan Schmidt 2026-02-22T18:15:01Z urn:sha1:28862ff3e312bf9dfb4fc8f9621f27f195d7d631 We validate that the reply looks like a valid message id as generated by tag_message_id and, for channel messages, that the reply is going to the same channel as specified in the message id. Since tag values do not currently go through spamfilter, this is an easy-ish way to ensure that it cannot be used as a backchannel for spam. 2026-04-09T17:41:27Z Ryan Schmidt 2026-04-09T16:14:56Z urn:sha1:61b53aeae8f4df388c4c6f3ca31dea88268259bd The sender must be in the channel mentioned by the tag and must be able to send messages to that channel. Since this is a hint for clients to display the received PM in a channel buffer, having the ircd strip the tag when the sender would otherwise not be able to talk in the channel will help reduce confusion and make chanop actions more effective in reducing perceived in-channel issues. 2026-04-05T19:44:06Z Ryan Schmidt 2026-03-29T04:48:30Z urn:sha1:ce3b170671eefd9a6612c62de7b8bd5c7ea329fb - Initialize hooks before the main log file, because if we send a snote due to failing to open a logfile, that calls a hook. Attempting to call a hook before hooks are initialized will cause the ircd to segfault. - Skip access() check for the logfile itself and simply check the return value of fopen(). This fixes a TOCTTOU race where an access check succeeds but something causes the file to become inaccessible between access() and fopen(), preventing an appropriate error from being logged. Also makes my life easier with my custom SELinux policy for the ircd since access() checks for full-write access whereas my policy only allows append access for logfiles. 2026-04-05T19:40:11Z Ryan Schmidt 2026-03-26T14:57:01Z urn:sha1:53ddbc4a9fdd26d7604cfdaac79deb33625398a7 2026-04-05T19:40:11Z Ryan Schmidt 2026-03-26T05:05:32Z urn:sha1:7b327076084b71ae7879f4d8cb1ad33e6ac229d4 The ban.db file as well as both MOTD files were in hardcoded locations. Add new config options to the main solanum binary to manipulate where these files are looked for. This should make it fully possible to run multiple solanum instances from the same directory side-by-side. 2026-03-25T20:47:47Z Aaron Jones 2026-03-25T20:40:23Z urn:sha1:d8d710c7bc052c3e24f76ca7a63da3a6ba6af8ea Fixes #510