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.
* update dependencies
* add some status badges
crates.io
testing status
dependency status
* add cargo-audit ci
* add dependabot for cargo and github actions updates
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.
* fixed the path for the certificates inside the docker container, it had changed with cpnfeeny's latest commit
* remove trailing slashes for docker bind mounts for better legibility
* add --name agate to give the container a name
