libathemecore/ptasks: handle status-prefixed channel messages #823
Conversation
If a channel message comes in with a status prefix, we should still treat it as a channel message. This does not raise concerns about chanops hiding the usage of fantasy commands because they can always private message services directly and the output of potentially-abusive commands (for example, kick) is signed off with their account name anyway (which will not change). Under the solanum family of IRCds, there exists a channel mode +z, which will transform messages to #channel into messages to @#channel if the message would have been blocked by +m/+b/+q. This is to clearly distinguish to channel operators that the only reason they are seeing the message is that they are operators, and that other channel users will not have seen it. ChanServ is also a channel operator, but it would not have received the message, because services ignored status-prefixed channel messages. This prevented users using fantasy commands if they are affected by +z; for example, by the channel being +m. Confusingly, this would have allowed "!deop" to work, but not "!op". Reported by juggs on IRC, who did not respond to a request for the proper attribution in Reported-by.
|
Looks fine to me. |
| */ | ||
| bool is_status_prefixed = false; | ||
|
|
||
| for (unsigned int i = 0; p == (target + 1) && prefix_mode_list && prefix_mode_list[i].mode; i++) |
There was a problem hiding this comment.
i feel like the inclusion of static logic in a for condition is needlessly abstruce. this took me 5 minutes to understand
There was a problem hiding this comment.
is there much at risk to just do
if ((p = strchr(target, '#')) != NULL)
{
(void) handle_channel_message(si, p, is_notice, message);
return;
}?
it feels like having an octothorpe in a target name when it's not ultimately a channel is a protocol framing issue
There was a problem hiding this comment.
This was proposed about a decade ago, but there was something wrong with it. I forget what it was now, though.
Honestly, it seems fine, we were probably bikeshedding about a non-practical issue.
There was a problem hiding this comment.
is there much at risk to just do
if ((p = strchr(target, '#')) != NULL) { (void) handle_channel_message(si, p, is_notice, message); return; }
Think of charybdis-family IRCds where you send a PRIVMSG to $#some.mask and #some.mask happens to be an extant channel.
|
hm, for solanum (via ts6-generic) we don't currently advertise support for we do advertise |
If a channel message comes in with a status prefix, we should still treat it as a channel message.
This does not raise concerns about chanops hiding the usage of fantasy commands because they can always private message services directly and the output of potentially-abusive commands (for example,
KICK) is signed off with their account name anyway (which will not change).Under the solanum family of IRCds, there exists a channel mode
+z, which will transform messages to#channelinto messages to@#channelif the message would have been blocked by+m/+b/+q. This is to clearly distinguish to channel operators that the only reason they are seeing the message is that they are operators, and that other channel users will not have seen it.ChanServ is also a channel operator, but it would not have received the message, because services ignored status-prefixed channel messages. This prevented users using fantasy commands if they are affected by
+z; for example, by the channel being+m. Confusingly, this would have allowed "!deop" to work, but not "!op".Reported by juggs on IRC, who did not respond to a request for the proper attribution in Reported-by.