* 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>
It is functionally fine not to, but causes objects to never be freed
if iter() is the only method called on the queue (ie. no
enqueue/dequeue, len(), ...)
This is consistent with what we already do with commands; and generally
makes sense, as we don't want to re-send titles and others when cycling
on UnrealIRCd (which includes a chathistory batch when joining when
chmode +H is set, despite umode +B)
They are not meant to be displayed like this, so they look weird sometimes.
For example, Mastodon splits long links between spans, so the Fediverse plugin
always displayed them broken.
nickFromHostmask now (legitimately) complains when it's getting @ or !
at the beginning of a hostmask; so we need to strip them before passing
it to nickFromHostmask.
Then re-add them before calling c.addUser, because it uses them to
sort users in the right sets (ops/halfops/voices).
Additionally, this commit replaces the hardcoded set of prefix chars
(`@%+&~!`) with the one advertised in ISUPPORT when possible.
* Fix joins to many channels
If you have enough channels that the 512 byte message limit on the JOIN
message is hit then limnoria was losing the channel that put it over the
limit and not including it in the next JOIN message. This resulted in
losing one channel for every JOIN message that pushed us over 512 bytes.
We fix this by generating the JOIN message immediately after resetting
the channels list to ensure we include the channel that pushed us over
the limit. Then the next time through our JOIN msg construction we'll
add subsequent channels without forgetting the one that pushed us over.
* Add test for channel join lists
This adds a test for the issue that is fixed in the previous commit. We
ensure that when JOINs are split over multiple messages we JOIN to all
channels that were part of the input list and don't forget any of them.
When the number of hostmasks exceeds 1000 (the hardcoded size of
_patternCache and _hostmaskPatternEqualCache), this triggers
a pathological case in the LRU caches, that causes all calls to be
a cache miss.
This means that on every IRC message received, ircdb.checkIgnored triggers
a recompilation of *all* user hostmasks, which is very expensive
computationally.
This commit stores them in their own cache to prevent them from
expiring.
It's pointless and looks stupid.
It will look even more stupid when we enable multiline, because the
suffixes will be in the middle of the concatenated message.
Otherwise, if some IP addresses don't work (eg. all odd ones), the bot will
consecutively fail because it can't connect, then connect + get STS + reconnect,
then fail again, then connect + get STS, etc.
This is not a regression; this was already forbidden before
23417b0675, and this commit was not
tagged/released yet at the moment I'm writing this one.
echo-message ended up in self.state.capabilities_req even though it wasn't
requested, so the bot was stuck in state:
"Waiting for ACK/NAK of capabilities: {'echo-message'}".
