jailbird777 [Fri, 25 Jun 2021 07:21:02 +0000 (02:21 -0500)]
(Mostly) exorcise select()
Sadly, this just sends it to purgatory. It's still around for the
socketpair() emulation and the nanosleep() emulation.
socketpair() obviously only selects() on 2 FDs, so not a huge deal.
nanosleep() only uses it for the timeout, so also not a huge deal.
socketpair() is SUSv3 (2001) and nanosleep() is SUSv2 (1997), so maybe
it's OK to remove those emulations. If so, then we can also remove the
sys/select.h check in configure.ac
jailbird777 [Thu, 17 Jun 2021 23:15:11 +0000 (18:15 -0500)]
Remove unneeded ugly hack for 32-bit Solaris
- The official Sun/Oracle solution is to use the extendedFILE(5)
mechanism, which works around the limitation.
https://docs.oracle.com/cd/E18752_01/html/816-5175/extendedfile-5.html
- Add a quick HOWTO to the README.md
Ed Kellett [Sat, 29 May 2021 15:47:17 +0000 (16:47 +0100)]
authd: substitute * if rewritten user is empty
We remove characters like ^ and ~ from the ident string after checking
if it's valid. If it consisted entirely of those, we'd try to send an
empty string to ircd, which would break the protocol, so don't let that
happen.
Aaron Jones [Fri, 4 Jun 2021 22:53:09 +0000 (23:53 +0100)]
modules/m_sasl.c: use IsSecure() instead of IsSSL()
Further to our implementation of the concept of "secure origins", we can
indicate to services that the client is connected securely, rather than
just that the client is using TLS. For example, connections from the
local host (from the IRCd's perspective) can be considered secure
against eavesdropping.
Allow this to factor into services' decision on whether to allow an SASL
negotiation or not. Atheme currently assumes this means the client is
using TLS, but I have changed that in atheme/atheme@412d50103c1d8c2a
Sadie Powell [Tue, 25 May 2021 10:08:59 +0000 (11:08 +0100)]
Remove the CLIENTVER 005 token. (#161)
This was introduced in commit bde6442c47 but the rationale for it is
pretty shaky. No other non-Charybdis-derived servers send it and the
features the original commit claims it can be used to detect all have
their own methods of detection. The concept of "core capabilities" and
versioned releases was also dropped by IRCv3 many years ago in favour
of living specifications.
Aaron Jones [Mon, 1 Feb 2021 08:35:44 +0000 (08:35 +0000)]
OpenSSL: Support configuration of TLSv1.3 ciphersuites
The OpenSSL developers decided, during the OpenSSL 1.1.1 development
phase, to use a different API and different set of lists for TLSv1.3
ciphersuites, than for every TLS version preceeding it.
This is stupid, but we have to work with it.
This commit also improves configuration fault resilience. The reason
is that if you don't pass any valid old-style ciphersuites, OpenSSL
will not negotiate an older protocol at all. However, when they
implemented the new API, they decided that lack of any valid
ciphersuites should result in using the defaults. This means that if
you pass a completely invalid ciphersuite list (like "foo"), OR if
you pass a TLSv1.2-only ciphersuite list, TLSv1.3 continues to work.
This is not mirrored; passing a TLSv1.3-only ciphersuite list will
break TLSv1.2 and below.
Therefore we work around this lack of mirroring by falling back to
the default list for each protocol. This means that if
ssl_cipher_list is complete garbage, the default will be used, and
TLS setup will succeed for both protocols. This is logged, so that
administrators can fix their configuration.
I prefer this approach over explicitly disabling the protocols if
their respective ciphersuite lists are invalid, because it will
result in unusable TLSv1.3 if people run newer solanum with their
older charybdis/solanum configuration files that contain custom
ssl_cipher_list definitions. Hindering TLSv1.3 adoption is not an
option, in my opinion.
The downside of this is that it is no longer possible to disable a
protocol family by not including any of its ciphersuites. This could
be remedied by an ssl_protocol_list configuration directive if it is
decided that this functionality is ultimately necessary.
This work is not required for either of the other TLS backends,
because neither of those libraries yet support TLSv1.3, and in the
event that they eventually do, I expect them to allow configuration
of newer ciphersuites with the existing APIs. This can be revisited
if it turns out not to be the case.
Signed-off-by: Aaron Jones <redacted> Tested-by: Aaron Jones <redacted>
Ed Kellett [Mon, 30 Nov 2020 09:24:32 +0000 (09:24 +0000)]
chmode: end the grace period more intelligently (#84)
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.
Doug Freed [Sun, 29 Nov 2020 01:03:29 +0000 (20:03 -0500)]
send: fix infinite recursion in _send_linebuf
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.
projects / solanum.git / log
