Strip formatting when calculating the timestamp width to avoid
moving a bunch of code around. Use styleAdd (now with an initial
style parameter) to show timestamps.
This allows changing the style of the timestamps from the default
gray using literal IRC formatting codes in the string. Not ideal,
but no new options needed.
Suggested by Hoël Bézier and Sebastian LaVine.
This fixes the case where an IRCd does not normalize channel names,
e.g. PRIVMSG #TEST is relayed as-is, rather than as #test or whatever
the canonical casing of the channel name is. It also fixes the case
of opening a query window with incorrect case, e.g. /query nickserv.
However, this solution is only completely correct when
CASEMAPPING=ascii.[1] I do not think the extra mappings of
CASEMAPPING=rfc1459 are relevant enough to justify adding the code
to handle it.
[1]: https://modern.ircdocs.horse/#casemapping-parameter
Otherwise a tag with no value would cause a segfault trying to
unescape the NULL tag pointer. This shouldn't happen for the server
tags we parse, but clients could send @+draft/reply with no value.
On OpenBSD it's in <fcntl.h>, and it gets declared anyway on FreeBSD
and macOS. Curiously, on GNU/Linux, LOCK_* are defined, but flock(2)
isn't declared.
caph_enter(3) is the same as cap_enter(2) except that it returns
success even if the kernel does not support capability mode. Since
we only enter capability mode when explicitly requested by the
restrict option, it should fail loudly if it is not supported. On
the other hand, we make calls to caph_rights_limit(3) and friends
in some places regardless of whether we actually enter capability
mode (to keep the code simple), so those should continue to succeed
even if capability mode is not supported.
Messages don't really need to be hidden from <network> and I think
it could be confusing. Debug messages are all Cold so everything
would be hidden, and I want to keep them that way so that <debug>
doesn't clutter the status line needlessly.
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.
C. McEnroe
psykose
Klemens Nanni