https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/?h=amdj%2Fautotools-version-fix 2026-05-12T08:22:44Z 2026-05-12T08:22:44Z Aaron Jones 2026-05-12T08:22:44Z urn:sha1:23f98f3457a418ce5238945c5e674a46263dda88 Commit 6ba61b33f7ec557c02c1 split this logic up from the top level Makefile.am but then failed to adjust the path to the directory in the check The result is that all builds now use a datecode of 0 and a revision of "unknown" 2026-05-11T18:04:40Z Ryan Schmidt 2025-07-16T18:08:20Z urn:sha1:44966b7ed496dac95e81f500b79ab28d818b707c A new flag ACT_BYPASS was added as a generic flag to bypass +u if set. Opers remain immune, both as senders and recipients, so that spamfilter cannot be abused to lock people out of managing filters, talking to services, etc. Three new configuration items were added to the general section of ircd.conf to control filter behaviour: - filter_sees_user_info: This replaces the old #defines for FILTER_NICK, FILTER_IDENT, and FILTER_HOST to determine whether the hostmask of the user is passed to the spamfilter or whether we pass a dummy *!*@*. - filter_bypass_all: If set, the new ACT_BYPASS can allow every filter action (DROP, KILL, ALARM) to bypass +u if set in conjunction with those flags. If unset, only the DROP action can bypass +u and ACT_BYPASS has no effect on other actions. - filter_exit_message: This is the quit reason displayed, to move it out of a #define (we still keep a define around for a default reason in case it is unspecified). If either filter_sees_user_info or filter_bypass_all are set, the VERSION command will display a new 'F' flag to indicate the ability for filter to spy on users. 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.