New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nick-/ChanServ: Registering "clear", "modify" or "list" breaks /msg ChanServ flags #channel clear/modify/list #397
Comments
|
This is rejected for Atheme, please consider reporting it to a downstream fork instead. |
kaniini
added a commit
that referenced
this issue
Nov 2, 2014
|
[This issue is not fixed until the patch is merged. It was closed for now obsolete reasons.] |
maxteufel
added a commit
that referenced
this issue
Mar 6, 2016
Previously, ChanServ FLAGS behavior could be modified by registering or dropping the keyword nicks "LIST", "CLEAR", and "MODIFY". Now, a configuration option is available that when turned on (default), disables registration of these keyword nicks and enables this compatibility feature. When turned off, registration of these keyword nicks is possible, and compatibility to Anope's FLAGS command is disabled. Fixes #397
maxteufel
added a commit
that referenced
this issue
Mar 6, 2016
Previously, ChanServ FLAGS behavior could be modified by registering or dropping the keyword nicks "LIST", "CLEAR", and "MODIFY". Now, a configuration option is available that when turned on (default), disables registration of these keyword nicks and enables this compatibility feature. When turned off, registration of these keyword nicks is possible, and compatibility to Anope's FLAGS command is disabled. Fixes #397
maxteufel
added a commit
that referenced
this issue
Mar 6, 2016
Previously, ChanServ FLAGS behavior could be modified by registering or dropping the keyword nicks "LIST", "CLEAR", and "MODIFY". Now, a configuration option is available that when turned on (default), disables registration of these keyword nicks and enables this compatibility feature. When turned off, registration of these keyword nicks is possible, and compatibility to Anope's FLAGS command is disabled. Fixes #397
siniStar7
pushed a commit
to XthemeOrg/Xtheme
that referenced
this issue
May 8, 2016
Previously, ChanServ FLAGS behavior could be modified by registering or dropping the keyword nicks "LIST", "CLEAR", and "MODIFY". Now, a configuration option is available that when turned on (default), disables registration of these keyword nicks and enables this compatibility feature. When turned off, registration of these keyword nicks is possible, and compatibility to Anope's FLAGS command is disabled. Fixes atheme/atheme#397
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is some kind of ironic "Anope compatibility" implemented in ChanServ here:
https://github.com/atheme/atheme/blob/master/modules/chanserv/flags.c#L195
It seems to be a feature, but it is completely weird, that any user can register the nicks "clear", "modify" and "list", resulting in a network-widely changed command syntax:
before registration:
"/msg ChanServ flags #channel list"
--> shows the flags for #channel
"/msg ChanServ flags #channel modify Username +-modification"
--> modifies the flags for Username on #channel
"/msg ChanServ flags #channel clear"
--> clears the channel's flags (!)
after registration:
"/msg ChanServ flags #channel list"
--> shows the flags for the user who grouped the nick "list"
"/msg ChanServ flags #channel modify Username +-modification"
--> [ChanServ] Invalid template name given, use /msg ChanServ TEMPLATE #channel for a list (!)
"/msg ChanServ flags #channel clear"
--> shows the flags for the user who grouped the nick "clear"
issues caused by this behavior:
This is highly theoretical, but it could actually lead to annoyance in certain cases:
This someone now wants to use the following command to first check the current flags of LoVeR:
/msg ChanServ flags #channel modify LoVeR
--> Expected result: [ChanServ] No flags for LoVeR in #channel.
Then they would like to use "/msg ChanServ flags #channel modify LoVeR +V" to give them the needed flag.
However, LoVeR quickly and silently - for example using an identified webchat in the background - groups the "modify" nick to their account. Now someone uses the command:
/msg ChanServ flags #channel modify LoVeR
...to see LoVeR's flags on #channel, as that has always worked like this. They got used to this Anope command syntax and are happy to be able to use it here, too. However, as "modify" is now grouped, the command will produce the following result:
--> [ChanServ] Flags +AVeiorstv were set on LoVeR in #channel.
Whoops, LoVeR got some permissions they should not have received, by changing the behavior of a services command just by grouping the "modify" nick to their account. Before someone understands what happened, LoVeR abuses their privileges.
As I said, it's a highly theoretical issue, but in my opinion, it should be fixed anyway. It should not be possible for users to change the behavior of services commands by registering nicks that happen to match command names.
The text was updated successfully, but these errors were encountered: