| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SHA256-based password hashing algorithm used by slcl(1) and
usergen(1) is considered insecure against several kinds of attacks,
including brute force attacks. [1]
Therefore, a stronger password hashing algorithm based on the Argon2id
key derivation function is now used by default. While OpenSSL does
support Argon2id, it is only supported by very recent versions [2],
which are still not packaged by most distributions as of the time of
this writing. [3]
As an alternative to OpenSSL, libsodium [4] had several benefits:
- It provides easy-to-use functions for password hashing, base64
encoding/decoding and other cryptographic primitives used by slcl(1)
and usergen(1).
- It is packaged by most distributions [5], and most often only the patch
version differs, which ensures good compatibility across distributions.
Unfortunately, and as opposed to OpenSSL, libsodium does not come with
command-line tools. Therefore, usergen(1) had to be rewritten in C.
In order to maintain backwards compatiblity with existing databases,
slcl(1) and usergen(1) shall support the insecure, SHA256-based password
hashing algorithm. However, Argon2id shall now be the default choice for
usergen(1).
[1]: https://security.stackexchange.com/questions/195563/why-is-sha-256-not-good-for-passwords
[2]: https://docs.openssl.org/3.3/man7/EVP_KDF-ARGON2/
[3]: https://repology.org/project/openssl/versions
[4]: https://www.libsodium.org/
[5]: https://repology.org/project/libsodium/versions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to the fdzipstream library [1] and zlib [2], it is possible to
generate ZIP files on-the-fly, therefore requiring no extra disk space
usage and only a small amount of memory.
Unfortunately, as of the time of this writing fdzipstream is not
packaged by any distributions yet [3], so it had to be imported as a git
submodule as a workaround.
While libarchive [4] could be an interesting alternative, writing ZIP
files is only supported by very recent versions (>= 3.8.0), which are
still not packaged by many distributions [5], either.
Moreover, libarchive is a package with several dependencies other than
zlib and is significantly larger compared to fdzipstreams, so
fdzipstreams was ultimately considered a better fit for this purpose.
[1]: https://github.com/CTrabant/fdzipstream.git
[2]: http://zlib.net/
[3]: https://repology.org/projects/?search=fdzipstream
[4]: https://www.libarchive.org/
[5]: https://repology.org/project/libarchive/versions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crealpath (for "custom realpath") is a custom implementation of
realpath(3) that aims to work similarly to GNU's realpath(1). This
implementation is provided due to the following reasons:
- Future commits will require extracting an absolute path from a
relative path, and/or process relative components from a path, such as
".." or ".".
- realpath(3) is defined by POSIX.1-2008 as a XSI extension, and
extensions are generally avoided in this repository whenever possible.
- Additionally, realpath(3) requires the file or directory pointed to by
the path to exist, which might not always be the case for slcl.
- auth.c uses its own implementation to extract a dynamically allocated
string by repeatedly calling getcwd(3). Future commits will also
require this future, so it makes sense to keep it on a separate
component.
|
| |
|
|
|
|
|
| |
Even if OpenSSL 1.0 is no longer supported [1], slcl still builds and
works fine with it, so there is no reason to require a higher version.
[1]: https://openssl-library.org/policies/releasestrat/index.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following commits fix a couple of security issues on libweb.
Because of afe0681c0b26bb64bad55d7e86770f346cfa043e, slcl had to be
updated to set up its struct http_cfg_post.
commit afe0681c0b26bb64bad55d7e86770f346cfa043e
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Mon Feb 19 23:00:56 2024 +0100
Limit maximum multipart/form-data pairs and files
A malicious user could inject an infinite number of empty files or
key/value pairs into a request in order to exhaust the device's
resources.
commit 9d9e0c2979f43297b2ebbf84f14f064f3f9ced0e
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Mon Feb 19 22:49:09 2024 +0100
html.c: Avoid half-init objects on html_node_add_attr
The previous implementation would leave half-initialised objects if one
of the calls to strdup(3) failed. Now, n->attrs is only modified when
all previous memory allocations were successful.
|
| | |
|
| | |
|
| |
|
|
| |
When VERSION is given, LANGUAGES becomes mandatory.
|
| | |
|
| |
|
|
|
| |
So far, slcl's build system would always build libweb and dynstr.
However, this is discouraged by distribution packagers.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
slcl has been successfully tested with OpenSSL 2.0 on an OpenBSD 7.3
host.
|
| |
|
|
|
| |
Otherwise, CMake by default tests the system C++ compiler, but this is
not a requirement for slcl.
|
| |
|
|
|
| |
Now, slweb is a library slcl depends on, which includes the HTTP/1.1
server implementation, as well as other utilities.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
slcl used to provide a hardcoded stylesheet. However, it would be
desirable for some admins to provide a custom stylesheet without having
to rebuild the application.
Now, slcl creates a default stylesheet, namely style.css, into the
target directory, that can be later modified by admins.
While this might contradict the suckless philosophy a bit, hopefully
some admins might find this new feature useful.
|
| |
|
|
| |
Future commits will make use of this function outside handler.c.
|
| |
|
|
|
|
|
| |
- Error detection against strotul(3) has been improved, as done in other
places.
- New function encode_hex has been implemented, which will be used
by future commits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature allows admins to set a specific quota for each user, in
MiB. This feature is particularly useful for shared instances, where
unlimited user storage might be unfeasible or even dangerous for the
server.
Also, a nice HTML5 <progress> element has been added to the site that
shows how much of the quota has been consumed.
If no quota is set, slcl falls back to the default behaviour i.e.,
assume unlimited storage.
Limitations:
- While HTTP does specify a Content-Length, which determines the length
of the whole request, it does not specify how many files are involved
or their individual sizes.
- Because of this, if multiple files are uploaded simultaneously, the
whole request would be dropped if user quota is exceeded, even if not
all files exceeded it.
- Also, Content-Length adds the length of some HTTP boilerplate
(e.g.: boundaries), but slcl must rely on this before accepting the
whole request. In other words, this means some requests might be
rejected by slcl because of the extra bytes caused by such boilerplate.
- When the quota is exceeded, slcl must close the connection so that
the rest of the transfer is cancelled. Unfortunately, this means no
HTML can be sent back to the customer to inform about the situation.
|
| |
|
|
|
|
|
|
|
|
|
| |
POSIX functions ftw(3) and nftw(3) do not allow passing an opaque
pointer to the callback they call, so it forces the use of statically
allocated data.
ctfw (from "custom ftw") is a custom implementation that solves this,
while also removing unneeded stuff.
This function will be used by future commits.
|
| |
|
