| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
If we supported disabling caps, there would need to be a corresponding
check and activeIncr().
|
|
|
|
|
|
|
| |
Since pounce responds to server PINGs itself and doesn't relay them
to clients, the only PING a client could be responding to is one
of pounce's, in which case it doesn't make sense to relay the PONG
to the server.
|
|
|
|
| |
Bumped on both send and receive.
|
|
|
|
|
| |
So that it can actually be logged to a file separate from any errors
or status messages. Also make sure only LF is used when logging.
|
| |
|
|
|
|
|
| |
This should hopefully prevent accidentally using CapSomething rather
than CapSomethingBit as an index in the future.
|
|
|
|
|
|
| |
Setting an AWAY message then disconnecting will no longer replace
the AWAY message with the default one. Reconnecting continues to
always clear AWAY.
|
|
|
|
|
|
| |
While the colors were easy to identify in blocks, the meaning of
arrows is easier to remember, and survive logs being pasted for
debugging.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Another bug caused by trying to support broken clients. I'm annoyed.
|
|
|
|
|
|
| |
This needs to be documented! But the documentation won't make any sense
until there's something that can implement the actual functionality of
the capability.
|
|
|
|
|
|
| |
The change to support broken clients with bad line endings broke the
interception of QUIT with no message parameter, because the CR is part
of the length passed to intercept.
|
| |
|
|
|
|
| |
LibreSSL is "a modified version of that library".
|
|
|
|
|
| |
Sigh. The robustness principle enables the proliferation of worse
quality software.
|
| |
|
|
|
|
| |
https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs
|
|
|
|
|
|
|
|
|
| |
This addresses pounce getting killed with "Excess flood" when it sends
NAMES commands for too many channels when a client connects. These
commands, as well as automatic AWAY commands, are by default throttled
to 5 per second.
Tested on freenode with 36 channels and 200ms interval.
|
|
|
|
|
| |
Duration is set to INT_MAX since pounce will never accept cleartext
connections.
|
|
|
|
|
| |
So the spec doesn't say I can use cap values in CAP REQ. But it also
doesn't explicitly say I can't.
|
| |
|
|
|
|
| |
It should indicate the position after having seen the tagged message.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
"Tag skip" like it's a speedrun :3
|
|
|
|
| |
I think for some caps we need to filter messages without origins.
|
| |
|
|
|
|
|
|
| |
Filter functions are dealing with lines not including CRLF, so they
already have extra space. serverFormat is using snprintf which wants to
always write a NUL at the end of the string.
|
|
|
|
|
| |
If a line was produced by another client, it won't have one from the
server.
|
| |
|
|
|
|
|
|
|
|
| |
This doesn't yet, but it will break the "robustness principle" according
to which a server "SHOULD NOT" assume that a client capable of parsing
one tag is capable of parsing all tags. In future, TagCaps will have all
other caps that use tags ORed into it, and only if the client supports
none of them will tags be filtered out.
|
|
|
|
|
| |
I still think this limit is unreasonably large in comparison to 512 for
the actual message.
|
|
|
|
|
| |
If there's no room left in the buffer, tls_read will return 0 (since we
gave it zero length to read into) and cause client->error to be set.
|