We were ending the flood grace period for any channel mode command other
than `MODE #foo [bq]` by means of a hardcoded check. I've moved that to
after we parse the mode string, so we can correctly identify all
requests to change modes and end the grace period on exactly those.
It would have been entirely possible to move the check even further down
and flood_endgrace on only mode commands that *actually* change modes,
but I don't like the idea of making it sensitive to external conditions.
A netwide snote eventually calls into this function again with the same
server as has already been determined is over its sendq. Mark the link
dead before sending the snote to avoid infinite recursion.
Incoming MODE processing is split into a parsing step and an execution
step, instead of a mode's effector function being involved in its own
parsing. Modes can no longer use custom logic to control their parsing,
and instead supply a combination of CHM_* flags to the parser. As a
result, we know before we try to effect any mode changes what all of
them will be.
The reauthorize hack for override is no longer necessary. A side effect
of its introduction was that `MODE #foo b x!y@z` no longer worked; in
removing it we restore that behaviour.
We gain the ability to reject various invalid inputs that:
- mutate or query unknown modes
- supply excess mode arguments
- query modes that can't be queried
In each case, whether we *should* reject it is an open question; for now
I'm rejecting the first one.
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.
Otherwise, sendto_channel_local_priv() will only distribute mode changes
to opers only. This is because HasPrivilege(target_p, "") will evaluate
as false due to the target not being opered.
Thanks to Devin Brown for bisecting this issue.
I'm preparing to PR a succession of privs changes with the ultimate goal
of severely limiting the scope of the binary oper/user dichotomy and
move conceptually distinct oper functions into their own privs.
Accomplishing this is a non-trivial task, and can wait, but it's
inconvenient now to have such functions enabled by the same mechanism
that grants any privs at all--so I'm moving all of them to a
transitional priv with the intention of eroding that later.
This removes some inconsistencies: first of all it applies to both
CONF_KILL searches by IP in find_address_conf, and secondly it applies
to find_kline, which would have been an edge case before.
rejectcache entries can now use either a K-line aconf or a static
string as a reason. This will be sent in a 465 numeric before the usual
ERROR. In the case of K-lines, it resembles the 465 you would have been
sent without being rejected:
; nc -s 127.6.6.6 127.0.0.1 5000
:staberinde.local 465 * :You are banned from this server- Temporary
K-line 4320 min. - abc123 (2019/12/31 01.07)
ERROR :Closing Link: (*** Banned (cache))
; nc -s 127.128.0.0 127.0.0.1 5000
:staberinde.local 465 * :You are not authorised to use this server.
ERROR :Closing Link: (*** Banned (cache))
to make the package build reproducible by default without
everyone having to discover the custom variable.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
This code assigns the plain integer to keep the code simple.
Otherwise we would have to deal with differences between GNU date
and BSD date or include extra build deps like perl or python.
/modrestart used to be implemented as a normal command and could crash
when used remotely because it would reload m_encap, which was on the
call stack at the time. This was fixed in 41390bfe5f. However,
/modreload has exactly the same problem, so I'm giving it the
same treatment.
Incidentally: This bug was first discovered in ircd-seven, where the
`/mod*` commands themselves live in the core, so m_encap was the only way
the crash could happen (and it didn't most of the time, because m_encap
would only be moved if you got unlucky). But `/mod*` are in modules in
charybdis, so /modrestart would have unloaded the code it was in the
middle of executing. With that in mind, I'm not sure how it ever
appeared to work.
