https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/extensions?h=amdj%2Fautotools-version-fix 2026-05-11T18:04:40Z 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: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-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-03-22T00:09:27Z Aaron Jones 2026-03-11T08:54:23Z urn:sha1:900b6f784d1ee77aef9927d330952296ccd1305d The macro does not use this parameter but nevertheless this is the only module in the tree to pass a string to it, and if a future macro were to use it, it could easily stringify the name by using the # preprocessor operator. 2026-03-19T10:27:23Z Ryan Schmidt 2026-03-18T23:42:09Z urn:sha1:f06fda5bbc1ce6a5fc858fc85f290e51fbd74e70 This has been recently ratified and suppresses NAMES output during channel joins when enabled, providing for a decent chunk of bandwidth savings. 2026-03-17T22:39:01Z Valentin Lorentz 2026-03-15T00:46:40Z urn:sha1:9a1ee1b64ed660164197e6362bcbedba2a9175ca 2026-03-17T20:22:38Z Ryan Schmidt 2026-03-15T23:28:55Z urn:sha1:3253a979e4d9230fbad9a1fb9e6fc8a81aebc4ce The previous commit addressed the issue with (most) function signatures, but forgot to update the caps themselves to be 64-bit. This fixes that, and finishes the remaining overlooked function signatures. 2026-03-17T20:22:38Z Ryan Schmidt 2026-02-22T17:27:38Z urn:sha1:5a49ac1a7187bcd9665a9e82e3c91fba0df1787e Also made full use of the Set/Clear macros across the codebase so there's fewer places to touch in the future if changes are needed. 2026-03-17T20:22:38Z Ryan Schmidt 2026-02-21T02:30:21Z urn:sha1:8978f885844957bef743e60aeae8bf8096025850 Instead of overloading the same field in a LocalUser, have separate fields for client caps vs server caps. While only one of these will ever be nonzero, it reduces error by making it explicit which set of caps is being checked. IsCapable and friends have been split as well, to IsClientCapable and IsServerCapable. Finally, both fields have been updated to uint64_t (server caps were approaching the current limit) and all APIs that reference caps updated to uint64_t as well (no more signed/unsigned mismatches).