Silencing all windows with `M-+' (across multiple catgirl instances)
can be cumbersome, so provide an option to hide events, JOIN/PART noise,
etc. by default (each window's threshold will persist across load/save
cycles, i.e. when using the `-s/save' option).
Started out as `-v | visibility = threshold' to set a specific level,
the idea of a simpler toggle comes from june, who also squashed other
bugs (as usual).
ircConnect() yields a connected TCP socket after which "inet dns" is
no longer needed.
Possibly having loaded private key material, it seems a tad more
comforting to speak TLS *after* dropping any network capabilities
(except for socket read/write to the IRC host, of course).
Instead of moving the final pledge into irc.c:ircConnect() and thus
complicating the code around pledge across two C modules, simply
stub out an mnemonic ircHandshake() and call that explicitly.
This restores behaviour gained with
981ebc4 "Remove explicit tls_handshake(3) from ircConnect" which
was reverted for other reasons.
No need to keep them at runtime; do so unconditionally for the sake of
simplicity.
Declare TLS config globally so ircConnect() can clear it and declare
both client and config statically as they are not used outside the irc.c
module.
This reverts commit 981ebc4f12.
This broke `-o' to print the server certificate; without explicit
handshake there will be no tls_read(3) in this short code path.
caph_stream_rights(3) doesn't exist before FreeBSD 13.0 and there's
no good reason to create that dependency. I still run servers on
FreeBSD 12.
This is a partial revert of cbc9545cb3.
No point in trying to load a self-signed server certificate which we
are about to get from the server in the first place.
No need to read client certificate/key files when all we want is the
server certificate: in TLS the server always sends its certificate
before the client replies with any key material, i.e. catgirl sending
client data is useless.
catgirl(1) synopsis also notes how these options are irrelevant in the
-o/printCert case.
As a result, ircConfig() no longer requires any filesystem I/O in this
case, so hoist the purely network I/O related pledge() call to enforce
this -- more secure, self-documenting code!
This reads somewhat clearer as code is grouped by features instead of
security mechanisms by simply merging identical tests/conditions.
No functional change.
Simplify logic and decouple the two features such that the code gets
even more self-ducumenting.
Previously `catgirl -R -l' would never unveil and therefore "proc exec"
could execute arbitrary paths without "rpath" as is usual unveil/pledge
semantic.
Now that `catgirl -l' alone triggers unveil(2), previous "proc exec"
alone is not enough since the first unveil() hides everything else from
filesystem; unveil all of root executable-only in order to restore
non-restrict mode's visibility.
This leaves yields distinct cases wrt. filesystem visibility
(hoisted save file functionality excluded):
1. restrict on, log off: no access
2. restrict on, log on : logdir write/create
3. restrict off, log off: all exec-only
4. restrict off, log on : logdir write/create, all else exec-only
In the first case `unveil("/", "")' could be used but with no benefit as
the later lack of "rpath wpath cpath", i.e. filesystem access is revoked
entirely by pledge alone already.
Practically, this does not change functionality but improves correctness
and readability.
The first call to ircFormat, which calls tls_write(3) in turn, will
perform the handshake anyway. This way the handshake happens after
the final pledge(2) call.
Otherwise resizing the terminal will end catgirl until a handler is
registered, e.g. while in ircConnect():
catgirl: tls_handshake: (null)
Hoist registration right after uiInitEarly() as earliest possible point
in main() since initscr(3) sets up various signals incl. SIGWINCH, i.e.
initialise `cursesWinch' afterwards to pick up curses(3)'s handler.
I think I didn't use these originally because they were misconfigured
on tilde.chat, but they work now, and supposedly server aliases
should be more secure/reliable.
d3e90b6 'Use libtls "compat" ciphers' from 2018 fell back to "compat"
ciphers to support irc.mozilla.org which now yields NXDOMAIN.
All modern networks (should) support secure ciphers, so drop the
hopefully unneeded list of less secure ciphers by avoiding
tls_config_set_ciphers(3) and therefore sticking to the "secure" aka.
"default" set of ciphers in libtls.
A quick check shows that almost all of the big/known IRC networks
support TLS1.3 already; those who do not at least comply with
SSL_CTX_set_cipher_list(3)'s "HIGH" set as can be tested like this:
echo \
irc.hackint.org \
irc.tilde.chat \
irc.libera.chat \
irc.efnet.nl \
irc.oftc.net |
xargs -tn1 \
openssl s_client -quiet -cipher HIGH -no_ign_eof -port 6697 -host
Klemens Nanni
C. McEnroe