| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
|
|
|
|
| |
Since effectively the difference between a nick origin and a server
origin is the presence of a dot.
|
| |
|
| |
|
|
|
|
| |
Finally something more reasonable for call sites.
|
| |
|
| |
|
|
|
|
|
| |
capsicum is too impractical and removing it will allow much more
straightforward code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is to keep TCP connections to clients from being idle for more
than 15 minutes, since regular PINGs from the server are answered
by pounce and not relayed to clients.
Note that there is still no timeout on poll(2) unless there are
need clients. We assume that we are receiving (and swallowing)
regular PINGs from the server at an interval shorter than 15 minutes,
so a poll(2) timeout would be pointless.
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
calico is passing us sockets it already accepted, so we don't need
inet anymore.
|
| |
|
| |
|
| |
|
|
|
|
| |
So each can be logged properly with its prefix.
|
| |
|
| |
|
| |
|
|
|
|
| |
Ported from catgirl.
|
|
|
|
|
| |
Always use insecure, and trust, clientCert, clientPriv are irrelevant
for printing the remote certificate.
|
|
|
|
|
|
|
|
|
| |
getentropy(3) is kind of an awkward function. May as well be generic
as possible and read some random bytes from /dev/urandom, since for
-x we don't really need to worry about being in some execution
environment where that's unavailable. I'm also happy to remove that
special-case include for macOS since its crypt(3) isn't even usable
anyway.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The next release will be 2.0 so these can be removed now.
|
| |
|
| |
|
|
|
|
|
|
| |
This removes the dependency on libcrypto.
Signed-off-by: Issam E. Maghni <issam.e.maghni@mailbox.org>
|
|
|
|
|
|
| |
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.
|
| |
|