You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 16, 2023. It is now read-only.
The cause for this is relatively easy to find out:
Maskmatch does not look at ISUPPORT closely, meaning that neither CHANMODES type A (channel modes with arguments) nor PREFIX (channel modes with arguments not includes in CHANMODES). It only looks at the number of arguments and assumes the modes it knows about are the only ones with arguments (with is rather silly behaviour, in retrospect.)
The "correct" fix for this would include looking into ISUPPORT CHANMODES and PREFIX and filter out modes (with their associated argument) that are not being listened to.
Because this module only resolves around masks, it's possible to work around all that hard work by validating whether the argument is a hostmask, and discarding it if it is not (which might still lead to issues, but I can't think of any and if it does happen you could filter it out with the maskmatch.matching_modes setting.
In this case the sloppy fix is more appealing to me than the correct fix, I can't guarantee I'll ever work in the proper fix, but if I can reduce the number of false positives to a near zero with a relatively simple fix I'm all up for it.
bug fix: works around a problem where modes with arguments are not being filtered out,
and instead maskmatch starts matching against the wrong argument.
This is a bit of a cheesy hack. Anyone is welcome to improve the logic on this.
relevant: Zarthus/weechat-scripts#3
Example: If I set a channel
-o+b test-nick *!*@you.are.banned
, maskmatch will try to matchtest-nick
part instead of*!*@you.are.banned
:The text was updated successfully, but these errors were encountered: