instead of on NestedCommandIrcProxy.
ReplyIrcProxy._sendReply expects action=True to imply noLengthCheck=True, but only
NestedCommandIrcProxy.reply() enforces the latter, not ReplyIrcProxy.reply().
This crash was introduced in 3c1c4a69e9927bcc7265b1d77fd1ab49cb55090e by
moving NestedCommandIrcProxy's .reply() to ReplyIrcProxy.
Now that we can return both account extbans and regular masks,
it makes sense to ban both.
Otherwise, adding 'account' to supybot.protocols.irc.banmask
means we banned only the account instead of the hostmask,
which arguably makes the ban weaker (/NS LOGOUT to evade)
And a new method .makeExtBanmask() as an alternative to .makeBanmask(),
so plugins can opt-in to extended banmasks when they support it.
'ignore' commands in Channel and anti-flood in Owner and Misc will
keep using .makeBanmask() because they use them as ignore masks in
ircdb.
A future commit will add support for 'account' in
supybot.protocols.irc.banmask, but it is not supported for now,
as that config value is also used for ignore masks
* ircutils: Fix incorrect log message on invalid STS policy
* STS: fix confusion over what a secure connection is
irclib computed 'secure_connection' when TLS is enabled and TLS certs
are checked; but ircutils used the value to parse STS policies, which
should only care about being TLS or not.
This commit fixes the incorrect parsing on unchecked-TLS, and triggers
a reconnect when a STS policy is encountered in this case, to force
TLS certs to be checked before storing the policy.
* Accept STS policies when reconnecting after getting it over cleartext
ircutils.parseStsPolicy() was passed self.driver.ssl which is the configured
value, even though the connection was forced to be TLS temporarily
* ci: Lower timeout
* Fix typo in test name
Co-authored-by: James Lu <james@overdrivenetworks.com>
---------
Co-authored-by: James Lu <james@overdrivenetworks.com>
Add a replyIrc parameter to ReplyIrcProxy to run a command on one network, but route the replies to another.
This fixes a long standing issue where replies for remote commands are often lost to the void, as the nick of the caller may not exist on the target network (or worse, it could belong to a completely unrelated person).
Closes GH-556.
Co-authored-by: Val Lorentz <progval+git@progval.net>
I fear putting it in callbacks would be overzealous and reset it
within the processing of the same message, eg. when using conditional
to set the 'ignore' tag before other nested commands run.
Specifically, the issue is with Anonymous using irc.noReply() in
the first call, preventing nested commands' result from being used.
Before this commit, the second and third responses in the test would be
only "1" and "2" instead of "1 ['foo']" and "2 ['foo']".
