9862b637c2
This alter the current state machine by adding S_HANDSHAKE as the initial state. There, we ensure we did the handshake and we check SNI. ATM we simply continue in S_OPEN, but later we can add virtual host checks there, and skip to S_INITIALIZING with an error state if the client is accessing a wrong host. |
||
---|---|---|
.gitignore | ||
ChangeLog | ||
INSTALL.gmi | ||
LICENSE | ||
Makefile | ||
README.md | ||
gmid.1 | ||
gmid.c | ||
gmid.h | ||
iri.c | ||
iri_test.c | ||
utf8.c |
README.md
gmid
dead simple, zero configuration Gemini server
gmid is a simple and minimal Gemini server. It requires no configuration whatsoever so it's well suited for local development machines.
Care has been taken to assure that gmid doesn't serve files outside
the given directory, and it won't follow symlinks. Furthermore, on
OpenBSD, gmid is also pledge(2)
ed and unveil(2)
ed: the set of
pledges are stdio rpath inet
, with the addition of proc exec
if
CGI scripts are enabled, while the given directory is unveiled with
rx
.
Features
- IRI support (RFC RFC3987)
- dual stack: can serve over both IPv4 and IPv6
- CGI scripts
- (very) low memory footprint
- small codebase, easily hackable
Planned features
- virtual hosts
Drawbacks
- 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.
Building
gmid depends a POSIX libc and libtls. It can probably be linked against libretls, but I've never tried.
See INSTALL.gmi for more info, but the build is as simple as
make
The Makefile isn't able to produce a statically linked executable (yet), so for that you have to execute by hand
make
cc -static *.o /usr/lib/lib{crypto,tls,ssl}.a -o gmid
strip gmid
to enjoy your ~2.3M statically-linked gmid.