optionally disable the sandbox on some systems The FreeBSD and Linux' sandbox can't deal with `fastcgi' and `proxy' configuration rules: new sockets needs to be opened and it's either impossible (the former) or a huge pain in the arse (the latter). The sandbox is still always used in case only static files are served.

gc FILE_EXECUTABLE

gc sandbox_executor_process

get rid of the CGI support I really want to get rid of the `executor' process hack for CGI scripts and its escalation to allow fastcgi and proxying to work on non-OpenBSD. This drops the CGI support and the `executor' process entirely and is the first step towards gmid 2.0. It also allows to have more secure defaults. On non-OpenBSD systems this means that the sandbox will be deactivated as soon as fastcgi or proxying are used: you can't open sockets under FreeBSD' capsicum(4) and I don't want to go thru the pain of making it work under linux' seccomp/landlock. Patches are always welcome however. For folks using CGI scripts (hey, I'm one of you!) not all hope is lost: fcgiwrap or OpenBSD' slowcgi(8) are ways to run CGI scripts as they were FastCGI applications. fixes for the documentation and to the non-OpenBSD sandboxes will follow.

encode file names in the directory index Spotted the hard way by cage

sort the MIME mappings and do a binary search to match

don't load the built-in list when using `types'

allow add_mime to fail add_mime nows allocate dinamically copies of the passed strings, so that we can actually free what we parse from the config file. This matters a lot especially with lengthy `types' block: strings that reach the internal mapping are never free'd, so every manual addition is leaked.

fix an out-of-bound access in start_cgi Long time ago, client->req was a static buffer so the memcpy was safe. However, it's been since moved to a dynamically allocated string, so it's very often smaller than sizeof(req.buf) (1024), hence the out of bound access which results in a SIGSEGV very often on OpenBSD thanks to Otto' malloc. The situation with the iri parser, client->req and how the request is forwarded to the other process needs to be improved: this is just a fix to address the issue quickly, a better one would be to restructure the iri parser APIs and rethink how the info is forwarded to the ex process.

swap try_client_by_id with client_by_id i.e. allow client_by_id to fail and return NULL. Initially I thought it was a good idea to shut down a server process if we receive an invalid client id as reply from one of our requests to the executor process. This turned out not to be correct since a client can (read: will) disconnect in the delay beteewn we acknowledge their request and the cgi script execution. The fastcgi and proxy handler already handled this situation, so they're unaffected. This allows an attacker to make gmid unresponsible by just making enough requests until they hit the right timing.

allow using a custom hostname for SNI during proxying add a `sni' option for the `proxy' block: the given name is used instead of the one extracted by the `relay-to' rule.

improve proxy error path properly release everything when during client_close if the request was managed by a proxy.

add `require client ca' for proxy blocks refactor the code that calls validate_against_ca into an helper function to reuse it in both apply_require_ca and (optionally) in apply_reverse_proxy.

proxy: allow multiple proxy blocks, matching options and validations as a side effect the order of the content of a server block is relaxed: options, location or proxy blocks can be put in any order.

allow to disable TLS when proxying requests