Key files are generally created in such a way that only the owner
of the file may read it. This is practised by other software, e.g.
openssl and thus seems like good behaviour for agate too.
A new CLI option --socket enables listening on UNIX sockets. This is
similar to the --addr option, but takes a path as argument.
If the given path already exists and it is a socket, attempt to remove
it before listening.
The port check was refactored to avoid the retrieval of the TCP port on
every request.
Alternatively, a semaphore could have been used which might be a bit faster,
but since the start up process is only used once this simpler solution is
not at a significant disadvantage while being much simpler.
If multiple unspecified addresses are used, issue a warning if listening to
it after the first time fails because the system probably already listens in
dual stack mode. Assumes that IPv6 and IPv4 are used. If such addresses are
passed in manually, thats the admins problem for setting up something stupid
in case it goes wrong.
resolves#63
This now causes an error message with the default bindings because on Linux
binding to both IPv6's [::] and IPv4's 0.0.0.0 results in a "port in use" error
When computing the filesystem path to serve, each URL path segment
appended to the content directory path must be checked to ensure that it
consists only of normal filesystem path components (and not the root
directory, .., drive labels, or other special components). Otherwise,
the following directory traversal attacks are possible:
- When an absolute path is pushed onto a PathBuf, the PathBuf will be
overwritten. If we don't check for absolute paths, Agate can be
tricked into serving an arbitrary absolute filesystem path via a URL
like gemini://example.com/%2Fetc/passwd
- The url crate eliminates all .. segments from the URL when parsing,
even when these are percent-encoded. However, .. can be injected
into the computed filesystem path by using a URL path segment that,
when decoded, contains more than one filesystem path component, like
gemini://example.com/subdir%2F..%2F../outside_content_dir
Furthermore, path separators appearing within a single URL path segment,
like escaped / (%2F), should probably not be considered structural [0].
That is, "a%2Fb" refers to a resource literally named "a/b", not "b" in
subdirectory "a". Thus we also check that a URL path segment represents
no more than one filesystem path segment.
[0] https://www.w3.org/Addressing/URL/4_URI_Recommentations.html
This is possibly also related to #60.
Instead of showing a generic not found error, this shows both the admin and
the user that the directory exists, but directory listing is disabled.
resolves#42resolves#49
I did not expect support for Ed25519 to be so bad as to receive multiple
complaints about it. I did expect some problems, hence why I provided the
--ecdsa flag. I had hoped support would be better to drive those who still
do not support it (while again there is no reason to not support this
algorithm!) to use it.
also adjusted the certificate creation example to contain a subject alt name
with a DNS entry. This is strictly speaking not required for the top level
certificate, but it doesn't hurt to include it and makes the example reusable
for all certificates.
