2021-01-11 13:51:25 +01:00
|
|
|
# gmid
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
> dead simple, zero configuration Gemini server
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-16 20:41:34 +01:00
|
|
|
gmid is a simple and minimal Gemini server. It can run without
|
|
|
|
configuration, so it's well suited for local development, but at the
|
|
|
|
same time has a configuration file flexible enough to meet the
|
|
|
|
requirements of most capsules.
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-16 20:41:34 +01:00
|
|
|
gmid was initially written to serve static files, but can also
|
|
|
|
optionally execute CGI scripts. It was also written with security in
|
|
|
|
mind: on FreeBSD and OpenBSD is sandboxed via `capsicum(4)`and
|
|
|
|
`pledge(2)`/`unveil(2)` respectively.
|
2020-10-02 19:39:00 +02:00
|
|
|
|
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
## Features
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-13 20:06:51 +01:00
|
|
|
- IRI support (RFC3987)
|
2021-01-11 13:51:25 +01:00
|
|
|
- dual stack: can serve over both IPv4 and IPv6
|
|
|
|
- CGI scripts
|
|
|
|
- (very) low memory footprint
|
|
|
|
- small codebase, easily hackable
|
|
|
|
- virtual hosts
|
2021-01-16 20:41:34 +01:00
|
|
|
- sandboxed by default on OpenBSD and FreeBSD
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2020-10-03 17:49:09 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
## Drawbacks
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
- not suited for very busy hosts. If you receive an high number of
|
|
|
|
connection per-second you'd probably want to run multiple gmid
|
|
|
|
instances behind relayd/haproxy or a different server.
|
2021-01-11 13:08:50 +01:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
## Building
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
gmid depends a POSIX libc and libtls. It can probably be linked
|
|
|
|
against libretls, but I've never tried.
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
See [INSTALL.gmi](INSTALL.gmi) for more info, but the build is as
|
|
|
|
simple as
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
make
|
2020-10-02 19:39:00 +02:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
The Makefile isn't able to produce a statically linked executable
|
|
|
|
(yet), so for that you have to execute by hand
|
2020-12-02 21:18:01 +01:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
make
|
|
|
|
cc -static *.o /usr/lib/lib{crypto,tls,ssl}.a -o gmid
|
|
|
|
strip gmid
|
2020-12-26 00:37:43 +01:00
|
|
|
|
2021-01-11 13:51:25 +01:00
|
|
|
to enjoy your ~2.3M statically-linked gmid.
|
2021-01-16 20:41:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
## Architecture/Security considerations
|
|
|
|
|
|
|
|
gmid is composed by two processes: a listener and an executor. The
|
|
|
|
listener process is the only one that needs internet access and is
|
|
|
|
sandboxed. When a CGI script needs to be executed, the executor
|
|
|
|
(outside of the sandbox) sets up a pipe and gives one end to the
|
|
|
|
listener, while the other is bound to the CGI script standard output.
|
|
|
|
This way, is still possible to execute CGI scripts without restriction
|
|
|
|
even if the presence of a sandbox.
|
|
|
|
|
|
|
|
On OpenBSD, the listener process runs with the `stdio recvfd rpath
|
|
|
|
inet` pledges and has `unveil(2)`ed only the directories that it
|
|
|
|
serves; the executor has `stdio sendfd proc exec` as pledges.
|
|
|
|
|
|
|
|
On FreeBSD, the executor process is sandboxed with `capsicum(4)`.
|