I only found out randomly that you could invite Sigyn into your channel with /invite Sigyn if you are a channel op, since that wasn't mentioned on either this repo's readme or the wiki. Imo it should be added to the readme at least, next to the #freenode-sigyn reference (where this is mentioned in the title, as I found out later as well).

Per title. I find that using monospaced for those (such as /msg invite Sigyn) looks visually better. PR soon.

opering up via password is a bit of a security problem. couldn't see anything for this already in the codebase

A lot of the time when Sigyn issues a warning to a user for their actions in a channel, it's not entirely obvious to the user what they did wrong - and as Sigyn doesn't offer any clarification on it either, they may continue doing something wrong without realising it. This can easily lead to users basically ending up in the middle of a minefield without any knowledge of what Sigyn is saying they shouldn't be doing.

A possible solution could be exposing the reason from the elif block above this line into the warning Sigyn gives, like:

"Your actions (%s) in %s tripped automated anti-spam measures [...]"

So they'd at least get some sort of hint as to what they're doing wrong (whether it be "massrepeat", "highlight", "notice" or another such violation).

It e.g. tells people to email freenode email addresseses and contains many freenode specific cloaks.

My only idea would be making network name an option or taking it from the server, but that doesn't resolve the issue entirely.

We are used to using OperServ AKILLs instead of klining directly and would like Sigyn to be able to do that too so we would see everything in AKILL LIST.

https://github.com/atheme/atheme/blob/a8f85e86722ac69c9a5260785f1a790afe347a91/help/default/oservice/akill

• having to write out a category name is cumbersome (imagine !dnsbl DNS/MX type hostname detected on IRC)
• dronebl listings can also take a freeform comment for additional info that should be distinct from category (currently hardcoded to "used by irc spam bot" in Sigyn, which is likely a good overridable default)
• having a default category encourages people to list IPs without concern for category (type 3 is often not accurate!)

I'd like to propose switching to category numbers or short names, as well as making categories mandatory:
KLINE 1440 *@1.2.3.4 :[...]|!dnsbl 19 vpngate ip
KLINE 1440 *@1.2.3.4 :[...]|!dnsbl vpn vpngate ip
KLINE 1440 *@1.2.3.4 :[...]|!dnsbl 6
where the format is !dnsbl <category> [comment ...] !dnsbl [<category> [<comment ...>]]

obviously this comes at the cost of making sure everyone is informed about categories, but i don't think it's unreasonable to ask for accurate listing details.

The argument to the unkline command should be matched case-insensitively against the kline list, as often chanops (including me, apparently) will type it manually and neglect case. I wouldn't worry about the weird []|{}\ stuff, just A-Z and a-z.

I'm not awake enough to patch this, but I suspect the fix is adding a couple of .lower() on the line https://github.com/freenode/Sigyn/blob/master/plugin.py#L887

Error: 'supybot.plugins.Sigyn.repeatPattern' is not a valid configuration variable.

This is the else tree of defcon(), but the code has been copied to roughly six other codepaths.

When defconf modes should be set but the bot has not enabled oper-override yet it will enable oper-override and not set defconf modes.
I believe this is because the latter is done in the else clause, but it probably shouldn't be in an else clause at all.

                i.defcon = time.time()
                self.logChannel(irc,"INFO: ignores lifted and abuses end to klines for %ss by %s" % (self.registryValue('defcon'),msg.nick))
                # todo check current bot's umode
                if not i.god:
                    irc.sendMsg(ircmsgs.IrcMsg('MODE %s +p' % irc.nick))
                else:
                    for channel in irc.state.channels:
                        if irc.isChannel(channel) and self.registryValue('defconMode',channel=channel):
                            if not 'z' in irc.state.channels[channel].modes:
                                if irc.nick in list(irc.state.channels[channel].ops):
                                    irc.sendMsg(ircmsgs.IrcMsg('MODE %s +qz $~a' % channel))
                                else:
                                    irc.sendMsg(ircmsgs.IrcMsg('MODE %s +oqz %s $~a' % (channel,irc.nick)))

Non-CTCP channel notices are treated just like CTCPs (Sigyn calls them "ctcp" too) which is quite confusing from an operator perspective.
In my opinion, it would make sense to separate detection of channel notices and channel CTCPs.

I add a non-re pattern in the case it was found, then try to match it in the same case and it won't match. It's converted to lowercasing. Simple patterns should probably be case insensitive.

13:20 <@hexa-> .addpattern 0 900 Want IRC ads? https://williampitcock.com/ 
13:20 <Sigyn> PATTERN: hexa- added #16 : "want irc ads? https://williampitcock.com/" 0/900s
13:20 <Sigyn> hexa-: #16 added
13:20 <@hexa-> .checkpattern Want IRC ads? https://williampitcock.com/
13:20 <Sigyn> hexa-: No matches
13:21 <@hexa-> .checkpattern want irc ads? https://williampitcock.com/
13:21 <Sigyn> 1 matches: #16

*** Notice -- ... added global X min. K-Line for [*@82.128.kjh.zuz] [Please do not spam users or channels...

The real host is available in WHOIS. On #freenode-sigyn I was given single character fix for this, but I think after updating I am editing the wrong spot and I think it wouldn't hurt being literally here.

2018-02-18T15:20:37+0200 Defendanto (Notice) BAD: [#canada] [email protected] (matches #6) -> *@149.154.npj.tjj

I think the last part should be the actual host rather than the cloaked one as that is what was klined.

If a user is voiced in a channel, it should be considered as being whitelisted for that channel, and so it shouldn't risk being banned in that channel. I am not saying that there was an incident where a voiced user was banned, only that this feature will offer me a whitelist that I can use. The same also applies by default to channel ops.

Sigyn's false positives are often caused by temporary channel patterns.

In my opinion, it would make sense to remove a channel's temporary patterns when a channel op notices such a false positive and issues the unkline command.

Probably related to the Python3 migration?

ERROR 2018-10-28T14:50:40 Spec: [<context for owner>, <context for text>]
ERROR 2018-10-28T14:50:40 Received args: []
ERROR 2018-10-28T14:50:40 Extra args: ['text']
ERROR 2018-10-28T14:50:40 Uncaught exception in ['checkpattern'].
Traceback (most recent call last):
  File "/home/sigyn/.local/lib/python3.5/site-packages/supybot/callbacks.py", line 1320, in _callCommand
    self.callCommand(command, irc, msg, *args, **kwargs)
  File "/home/sigyn/.local/lib/python3.5/site-packages/supybot/utils/python.py", line 90, in g
    f(self, *args, **kwargs)
  File "/home/sigyn/.local/lib/python3.5/site-packages/supybot/callbacks.py", line 1286, in callCommand
    method(irc, msg, *args, **kwargs)
  File "/home/sigyn/.local/lib/python3.5/site-packages/supybot/commands.py", line 1093, in newf
    f(self, irc, msg, args, *state.args, **state.kwargs)
  File "/home/sigyn/config/plugins/Sigyn/plugin.py", line 658, in checkpattern
    self.log.info('%s : %s (%s)' % (pattern.uid,text,pattern.match(text)))
  File "/home/sigyn/config/plugins/Sigyn/plugin.py", line 365, in match
    s = self.pattern in text
TypeError: a bytes-like object is required, not 'str'
ERROR 2018-10-28T14:50:40 Exception id: 0x7c545

So far we have only managed to have Sigyn KLINEing after either manually added pattern has been triggered or something has been considered as flooding.

Line that doesn't get detected is: [14/16:55:40]<Pirate_57771> Defendanto: Fletcher Kunsido Mikaela Mikaela2 MikaelaX Pirate_57771

irc.net CAP Mikaela LS :account-notify account-tag away-notify cap-notify chghost echo-message extended-join invite-notify multi-prefix sasl=PLAIN,AUTHCOOKIE,EXTERNAL,ECDSA-NIST256P-CHALLENGE server-time tls userhost-in-names

if we preemptively store this information for each user in memory, when it's given to us in a cliconn snote (ignoring 255.255.255.255), prefixToMask doesn't have to deal with deferred actions like the threaded self.resolve and WHOWAS lookups. lack of maybe-deferred actions would make the code a lot simpler.

ⓘ [465] You are banned from this server- Temporary K-line 1440 min. - [#291] 644032 - flood 5/5s in #test (2018/3/17 19.13)

I think this information was intented to be only visible for opers?

By using KILL first, it will have the custom KILL message, but also lets the client to partially reconnect before actually getting KLINEd. I am not sure if you are considering this as an issue though.

Sigyn sends a message when she detects a suspiciously-large number of joins from one person:

19:49 <+Sigyn> NOTE: [#freenode] suspicious joins of someuser alts (gecos)

This detection does not currently take into consideration whether the JOIN is immediately after a "Changing host" fakequit, and thus triggers incorrectly more often than not. It would probably be worth coding it to do so, or perhaps changing the default threshold to consider this case.