| Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
And send an accurate total badge count.
|
|
|
|
It seems some IRCds don't even parse this correctly. It also should
never have been done this way since it breaks sending channel keys.
|
|
|
|
|
|
LibreTLS in particular is gaining traction in packaging, so point
to Repology pages to make users' lives easier.
|
|
|
|
Don't search base directories if path starts with "/", "./" or
"../", but still do if the path simply starts with ".". Bail early
if HOME is needed but unset. Don't attempt to open the original
path in configOpen and dataOpen.
|
|
|
|
Only request it with labeled-response, since it is impossible to
correlate messages to clients without. For clients without echo-message,
synthesize a label on PRIVMSG/NOTICE/TAGMSG, then filter out received
messages with that label.
|
|
|
|
|
|
Don't wait for getopt_long to move all the arguments to the end. This
allows overriding options set by config files by placing flags after
them on the command line.
|
|
Or only unsupported caps. Or, as the corresponding commit in catgirl
says, "if CAP LS doesn't list anything good."
|
|
|
|
Not totally clear under what conditions 437 is returned, but if it
happens during registration, we should pick a new nick.
|
|
This fixes building on 32-bit platforms.
|
|
I think this emulates SO_REUSEADDR, which for some reason doesn't work
on PF_UNIX. If the socket exists, check if connect(2) works, rather than
clobbering the socket being used by a still-running instance.
|
|
|
|
I don't think this is worth adding a configuration option for since real
clients will definitely accomplish registration faster than 10s and it's
long enough to even type out manually for testing.
|
|
Otherwise the successful authentication message can leak information to
unauthenticated clients when both certificate and password
authentication are enabled.
|
|
Except for during writes. This prevents pounce getting blocked on a
client sending only a partial TLS record, for example.
Writes still need to block because pounce doesn't have a way to resume
them. (And it would do so by having a buffer, but sockets already have a
send buffer, so what would be the point of that?) I don't think it
should be a problem since outside of stateSync, writes only happen when
poll returns POLLOUT. I feel like ideally SO_SNDLOWAT would be set to
guarantee a full IRC message can always be written on POLLOUT, but since
it's actually TLS records being sent, it's not obvious what the size
would be.
I'm also making an assumption here that tls_read returning
TLS_WANT_POLLOUT is unlikely to happen, since I don't actually set
pollfd.events based on that. I'm not sure how wanting to resume a
tls_read after a POLLOUT could be cleanly handled. I'm just going to
hope that if it does happen, the regular poll loop will eventually sort
it out...
|
|
|
|
|
|
|
|
Otherwise a client could cause pounce to hang (since the sockets are
left blocking) by opening a connection without handshaking! Oops,
that's pretty bad. Since the sockets are still blocking, a hang can
still be caused by a client sending a partial handshake then waiting.
More fixes to follow.
pounce is slightly protected from this when used with calico, as it
applies a timeout to waiting for the ClientHello.
|
|
My thinking here is that it's better to not allocate in response to
incoming connections. This also just makes the code a little simpler.
|
|
|
|
|
|
|
|
Somehow I never knew about this function. Much better than fmemopen with
mode "w".
|
|
This is a long-standing issue I ignored.
|
|
It won't be, but gcc thinks it might.
|
|
|
|
|
|
|
|
|
|
|
|
unveil(2) is a bit complicated to apply to this, I'll have to think
about it more.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|