os_chantrap functionality

[KoraggKnightWolf]

Dear genius3000,

Thank You for creating this module, it can be used well to keep unwanted channels (e.g. used by botnets) unusable. There are some things that do not appear to be as described though.

1. in the code it says it does NOT use BotServ bots yet it appears do this: a) it assigns OperServ b) it will then assign more BotServ bots in alphabetical order until the botcount is reached

2. Despite setting different kill and akill reasons in the config and reloading once again with those set to be certain, the default examples that it came with are always used as reason

3. It appears that a chantrap channel can be registered AFTER it was made a chantrap channel.

I hope that this feedback is of use to You and that if I am misunderstanding some functionality that
after some explanations I will be able to utilize it better.

Regards,

Koragg

[genius3000]

Thanks for the feedback.

1. It is very much intended to use existing bots and only create if necessary. Where are you reading does NOT use BotServ bots?
2. Nice catch, I've got a typo in the conf reading code. You can workaround this until I fix it by using kill_reason and akill_reason, note: just add the underscore.
3. Minor as only opers can remain joined but yeah I should forbid registration on these.

[KoraggKnightWolf]

You are very much welcome, I enjoy helping out as much as I can.

1. I gathered that from this line: https://github.com/genius3000/anope-modules/blob/master/os_chantrap.cpp#L67 where it states: We create bots separate of the BotServ system, we don't want these being used elsewhere

2. I modified the source code lines for now as that seemd the fastest workaround to me (of course it should read the values out as by design)

3. I registered it to use it so I can set bans on people who are likely good (those logged into an account, with valid ident responeses and on SSL) and it is a bit odd it states that it does e.g. /cs set options yet /cs info only states it is a chantrap channel info line.

If registration is completely turned off, can one also enforce bans with the modes option? if not, could certain users, at least those registered and identified, be exempted from being able to join? (opers should be able to override this perhaps)

Regards,

Koragg

[genius3000]

1. That line means exactly what it says and is a comment to the code for local bot creation. It says nothing in regards to not using existing bots as that's both false and irrelevant to that code segment.
2. So you'd like to be able to register these channels? I don't believe the local modes will work as you intend without an oper idling in there, so registration and keep modes or persist is the only way. The info issue is because it overrides the entire info command as intention was to chantrap unregistered channels.

[KoraggKnightWolf]

1. Thank You for the clarification of how it would operate

2. Perhaps it is useful then allowing the channels to be registered to use keepmodes and persist

3. If registration should be forbidden, also registering after the spamtrap creation, could there be exceptions, at least for authed users?

Regards,

Koragg

[TehPeGaSuS]

Exempting authed users would be probably a good idea.
Or even a way to make the channel "invisible" when an authed user do /list?

IMHO, registration should be forbidden and make it probably create a database with the settings specified for that channel, so settings are kept persistent in some way?

And yes, UnrealIRCd has the ability to prevent a user to change to a banned nickname, but the functionally is currently broken, although seems to be fixed for the next release (4.2.1).

[KoraggKnightWolf]

wouldn't +s or +p be enough to hide it though? as that also effects authed users and you can set non parametric modes when creating a chantrap
it appears to be saving them somewhere as /cs info is up to date with it being a chantrap channel

[genius3000]

It's simply just saved in the chantrap list, I hook to the INFO command and override it for any chantrap matches.
I'll review how I handle the modes thing and think about the possibilities of each path here (registration allowed or not, etc). I can say right now that I don't want to add any exceptions in a global basis, at the least they'd be configurable on/off. Maybe I should add a chantrap settings command, set different variables to an existent chantrap channel.

[KoraggKnightWolf]

An /os chantrap set subcommand for per channel tweaking including of some exceptions sounds like the best and most flexible approach. As another suggestion, could one also add a topic when creating a chantrap channel? This way staff can point out that it is such a channel if this is desired to "warn" innocent people from stepping right in. Does that sound like an option that could be implemented as well?

Thank You very much for Your time and effort in advance and also for consistently improving Your modules!

Regards,

Koragg

[genius3000]

Topic could definitely be another SET option if I implement that.

[KoraggKnightWolf]

Another option would be that the kill or akill msg could have e.g. a $chan identifier, referring to the specific channel that triggered it, for clients that might not show the disconnect messages in that channel but just in the status window (helps to reduce confusion which channel).

[genius3000]

Alright, this sounds like a partial re-write is the best route (command-wise). Here's what I'm thinking:

• Change ADD to just ADD mask reason.
• Add SET mask ___:
  • bots - number of bots (0 == inactive; 1+ == active; regex/wildcard are always inactive)
  • action - KILL or AKILL
  • duration - AKILL duration
  • message - message used in KILL or AKILL
  • modes - modes set on channel (active == always set; inactive == when an oper joins)
  • topic - topic on channel (same rule as modes)
  • exempt-ssl - Exempt any SSL users, but kick/ban them (like a forbid)
  • exempt-auth - Exempt any authenticated users, but kick/ban them (like a forbid)
• Defaults to be configurable with code-defaults of: 0, KILL, 0, current default, unset, unset, false, false.

Any thoughts or suggestions?

[KoraggKnightWolf]

Looks good, not sure if adding an exemption for users already in channel would be helpful (like Inspire's +b j:*) and perhaps also one to exempt-identd for those who have valid identd? (could default to off, also both of them) Another possible exemption might be those using cgi:irc. Just an idea for potentially more exemptions, of course only if they seem sensible.
Thank You very much for your modules and for seeking ways to constantly improve them.

Regards,

Koragg

[genius3000]

I'm not really for the whole need of exemptions in the first place. A good channel name and even a topic is enough, if users still wish to join and get zapped...so be it. I will though do the authenticated and SSL exemptions as they can be reliably determined (SSL via a usermode for some IRCds).