pounce, branch 2.1 IRC bouncer https://git.causal.agency/pounce/atom?h=2.1 2020-11-23T22:11:02+00:00 Unlink existing UNIX socket if it can't be connected to 2020-11-23T22:11:02+00:00 C. McEnroe june@causal.agency 2020-11-23T21:49:22+00:00 urn:sha1:83dcb6f4856198b92431a0281922f26f0734ff56 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. Clean up main loop loops 2020-11-22T00:59:44+00:00 C. McEnroe june@causal.agency 2020-11-22T00:59:44+00:00 urn:sha1:1f69284a2648ae895f60caa0126d6fd808f2ad23 Add lazy client registration timeout 2020-11-20T22:43:51+00:00 C. McEnroe june@causal.agency 2020-11-20T22:43:51+00:00 urn:sha1:faebbec64b4b36f608dbb0af20b5763ba1281b9b 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. Only allow clients to AUTHENTICATE if using a cert 2020-11-16T23:46:15+00:00 C. McEnroe june@causal.agency 2020-11-16T23:46:15+00:00 urn:sha1:eea44a8ad89a7c3ee2c8647e21c007b5250b4fb9 Otherwise the successful authentication message can leak information to unauthenticated clients when both certificate and password authentication are enabled. Set client sockets non-blocking 2020-11-16T20:04:39+00:00 C. McEnroe june@causal.agency 2020-11-16T20:04:39+00:00 urn:sha1:09af6dcd618701bc5994b4a146e6df34e1cf9015 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... Swap localAccept parameter order 2020-11-14T16:47:26+00:00 C. McEnroe june@causal.agency 2020-11-14T16:47:26+00:00 urn:sha1:70c3c9156a64c9053978e499328a121757628ed2 Only send shutdown QUIT and ERROR to registered clients 2020-11-14T16:31:27+00:00 C. McEnroe june@causal.agency 2020-11-14T16:31:27+00:00 urn:sha1:b315f738081a31cb44f2d8a9a545894576a8d455 Make struct Client public 2020-11-14T16:24:55+00:00 C. McEnroe june@causal.agency 2020-11-14T16:24:55+00:00 urn:sha1:7229eee4b507ab14f7553a14cba4f009a716bcde Wait for POLLIN to do client tls_handshake 2020-11-14T02:56:46+00:00 C. McEnroe june@causal.agency 2020-11-14T00:57:51+00:00 urn:sha1:bba1229c863469f7b3541d525af1f0e07e1ccdd1 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. Use a fixed size pollfd array in calico 2020-11-13T06:47:20+00:00 C. McEnroe june@causal.agency 2020-11-13T06:47:20+00:00 urn:sha1:264df02658ee7bca1ff7b1391f4b2494846f9c1a 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.