rework mark_nonblock so it sets the cloexec flag too and use it in control.c to avoid these flags. (which are expected to become available on a future revision of POSIX and are already widely available.) It's not an issue for telescope to do the socket/accept + fcntl dance because there aren't threads that can fork(2) (there are no threads at all!) reported by @sikmir at github https://github.com/omar-polo/telescope/commit/59ef79dd19611c7846b00427e6f2267c748ae290#r74498414

clang static analyzer found a possible use after free: if the code is not 2X in gemini_parse_reply we call close_conn. Then, in net_read we set req->done_header, but req may have been free'd! Actually, this is almost impossible to trigger. close_conn never ends up calling free(req) on its first try, because tls_close takes a while and is rescheduled by libevent. (The check req->ctx != NULL in close_conn is always true if it's a gemini request.) Nevertheless, it's clear to move close_conn out of gemini_parse_reply and simply return the response code: it feels wrong that a "parsing function" takes logic decisions.

it's not spelled `util.h' because otherwise it'd get included instead of /usr/include/util.h

this is just to simplify the future additions of client certificates.

thanks mansfield for breaking your server so I notice this error

imsg can't handle buffer "too big" (around INT16_MAX) and solene@ capsule index is ~29K. The 4K chunk size is completely arbitrary.

instead of defining macros in compat.h. It's clearer that it's only for libevent2 this way

it seems that we can "melt" :P the evbuffer from the start to avoid the unfreeze/freeze dance

on libevent2 we need to wrap evbuffer_add with evbuffer_freeze/evbuffer_unfreeze. Not sure exactly why, probably because we're doing some evbuffer_enable/disable/enable-again. Retain compatibility with the custom libevent1 in base on OpenBSD.