This doesn't make sense in a world where post-registration SASL is
allowed, and should fix one case of an annoying login desync that's seen
in the real world.
Specifically, when a client sends its final AUTHENTICATE and Atheme
receives it, it sends an SVSLOGIN for that client. If the client sends
us its CAP END *before* we see the SVSLOGIN, the implicit abort will try
to abort the SASL session that's already succeeded.
Atheme interprets this as an instruction to forget about the successful
SASL session; you'll connect unidentified. But it's already sent
SVSLOGIN, which will log the client in ircd-side, causing ircd and
services views to differ until the user authenticates again manually.
I think allowing a SASL session to be aborted when it has already
succeeded is an Atheme bug, and it can still be triggered without this
change. But our behaviour here seems silly anyway.
the logic for trying to detect the maximum value of time_t was broken;
since we target a lower maximum time anyway, just use that for the
overflow check
The algorithm we're using gets stuck if it has a ? and can only see a *
to feed to it, even if it could skip over that * and consume a character
following it. Remedy this by rearranging the input so * always precedes
? in runs of wildcards, so when we're matching ? we know we can skip
things.
Move opername and privset storage to struct User, so it can exist for
remote opers.
On /oper and when bursting opers, send:
:foo OPER opername privset
which sets foo's opername and privset. The contents of the privset on
remote servers come from the remote server's config, so the potential
for confusion exists if these do not match.
If an oper's privset does not exist on a server that sees it, it will
complain, but create a placeholder privset. If the privset is created by
a rehash, this will be reflected properly.
/privs is udpated to take an optional argument, the server to query, and
is now local by default:
/privs [[nick_or_server] nick]
Test serv_connect followed by exit_unknown_client.
An outgoing connection should not delete an incoming connection that
occurs during the connection attempt.
So that tags are added in the same order every time.
# wanted: @time=2017-07-14T02:40:00.000Z;account=test :LChanPeon!username@example.test TEST #placeholder :Hello World!
# seen: @account=test;time=2017-07-14T02:40:00.000Z :LChanPeon!username@example.test TEST #placeholder :Hello World!