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.
This information is basically useless anyway and fills logs needlessly.
Because this is not necessarily true for the local port because multiple ports
may be selected for hosting, logging for the local socket address is unchanged.
Moved updating the changelog from the quality standards up to the workflow
section so it should not be missed, since it is not really a quality standard
but an action to be performed.
adresses comments from #33
Loading the certificate and key file is done at startup because:
1. We can detect the incorrect file faster and fail the whole server and not
just a worker thread. All subsequent worker threads would fail for the same
reason anyway.
2. We do not have to read the same unchanged files over and over again. This
is good because file I/O is slower than in-memory cloning instead.
