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.
I had the idea that maybe these should be case-sensitive because some
encodings (like Base-64) are. But it turns out it's better to
prioritise not breaking existing configurations / channel mode lists,
and just revisit this in future maybe.
[ci skip]
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.