Commits
Commit:
0e49c9bbcbfef05d5bdf9ad6d851f51fe25c2eaa
Date:
Fri Jan 21 09:53:47 2022
UTC
gemini_parse_reply: return code and don't close connection
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.
Commit:
3591e6dbd5cf94dae2b0a438542bf542ae094c01
Date:
Thu Jan 20 13:25:22 2022
UTC
declare data as uint8_t *; pointer arith on void * is a GNU extension
Commit:
9d65b1d9ae3209a8a2bc8e8c376dede4f71290ce
Date:
Tue Jan 11 17:21:40 2022
UTC
move util.c declarations in utils.h
it's not spelled `util.h' because otherwise it'd get included instead
of /usr/include/util.h
Commit:
b38d86fca3af1c2c70cb97317ff78eace3ccf262
Date:
Tue Jan 4 13:26:57 2022
UTC
re-create the tls_config for each request
this is just to simplify the future additions of client certificates.
Commit:
98cba69edd2a59f4adc1f73880f12bb882b30fa7
Date:
Wed Nov 10 11:41:58 2021
UTC
handle empty replies (i.e. no header)
thanks mansfield for breaking your server so I notice this error
Commit:
0e8f22ed5bac3d23402a29c24f7dee6cd75add5b
Date:
Sun Sep 12 10:48:05 2021
UTC
send received page in chunks
imsg can't handle buffer "too big" (around INT16_MAX) and solene@
capsule index is ~29K. The 4K chunk size is completely arbitrary.
Commit:
95a8c791ec85e7b79a1975e82a22f7c07dbb9107
Date:
Thu Aug 26 10:40:55 2021
UTC
fmt (some missing space -> tab conversion)
Commit:
b5c5e56dce958046e26bea8b2449c806e9cdd642
Date:
Wed Jul 28 09:19:18 2021
UTC
wrap unfreeze in ifdef
instead of defining macros in compat.h. It's clearer that it's only
for libevent2 this way
Commit:
73bb7969cfc48e90a10200bd6b1c8c1ed9aff4f2
Date:
Tue Jul 27 21:05:51 2021
UTC
unfrozen by default
it seems that we can "melt" :P the evbuffer from the start to avoid
the unfreeze/freeze dance
Commit:
4c7d2b8fffba7a465cba957f823bc24d1d64cc04
Date:
Tue Jul 27 21:01:54 2021
UTC
buffer is frozen; drain becomes a NOP
Commit:
1470eab31452d2fab50bc4965320dab7892b2ef3
Date:
Tue Jul 27 08:41:42 2021
UTC
fix bufferevent tls I/O on libevent2
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.
Commit:
590c00b776ba5daed0a5dcb4b65f0d2faefac615
Date:
Sun Jul 25 12:36:28 2021
UTC
drain read buffer before EOF
Commit:
1663bf1e97e8a9f54bb78bfe8853f81c8e99e6db
Date:
Sun Jul 25 11:06:51 2021
UTC
initial gopher support
Commit:
5fb52fc04465f7828ef88810d153e77c705efa57
Date:
Sun Jul 25 10:01:20 2021
UTC
support finger:// urls!
Commit:
69f631d93578026c42de78c0165983c036f7b135
Date:
Sun Jul 25 09:58:39 2021
UTC
fix possible overflow
sizeof(buf) should be equal to howmuch, otherwise we may end up reading
with tls_read out of bounds and corrupting the stack.
Omar Polo