Small and lightweight cloud storage written in C99 and POSIX.1-2008. https://gitea.privatedns.org/xavi/slcl/atom?h=v0.4.2 2026-02-08T21:14:37+00:00 2026-02-08T21:14:37+00:00 Xavier Del Campo Romero xavi92@disroot.org 2026-02-08T21:08:58+00:00 urn:sha1:dd1ceb550c13d433cd26191ec3176eca0e2d70a1 If users send no payload data to a POST request, libweb sets a null pointer as part of the payload. Therefore, null pointers must always be checked as a sanity check. 2025-10-09T10:35:19+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-09T10:35:19+00:00 urn:sha1:efde6c777e7e40d5469835813284a9f373df46c1 2025-10-09T08:52:48+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-09T08:52:48+00:00 urn:sha1:d08e10515211f6d6c549b36894af02c2d021832f This functionality was moved from slcl to libweb since it can be shared with other web applications. 2025-10-08T20:55:44+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-08T11:50:52+00:00 urn:sha1:10e42591ac72285736d5cc4ee5e7c2f68dbf1e4b 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 2025-10-08T00:03:17+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-07T23:59:05+00:00 urn:sha1:805630dbfcd409a5d49bc89102f4183b71f713f9 libweb now supports deallocating user-defined data whenever an error occurs during a chunked transfer or an asynchronous HTTP response, thus avoiding memory leaks. 2025-10-08T00:03:05+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-06T21:02:51+00:00 urn:sha1:00dd37604d50cbf3fb27ec0631b4d4b6d2ee893a 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 2025-10-06T19:06:04+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-06T19:06:04+00:00 urn:sha1:485a9a4cc305aa0c24ac687ee3e4bc469dca16ee libweb now allows to set up a custom value for the backlog argument in the internal call to listen(2). 2025-10-06T14:28:59+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-06T13:53:11+00:00 urn:sha1:fda1fed7c88549030523350c0a3f337e49bbf868 Commit 4fa1b3e8 missed to update other calls to cftw that were still relying on the older interface, causing unexpected errors. As a side effect, user quotas are now calculated asynchronously i.e., without blocking other clients. While the same improvement was planned for the /rm endpoint, it proved too challenging to implement for a first refactor: on one hand, /rm takes one or more key-value pairs involving the top-level directories and/or files to remove. On the other hand, every directory must be traversed recursively as rmdir(2) must be used on empty directories. While certainly possible, it was considered to keep a synchronous behaviour for do_rm for the sake of simplicity. 2025-09-24T14:36:09+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-09-24T14:36:09+00:00 urn:sha1:21e4130e9e43a7d4d89f623b65eae3f40b29e2ed 2025-09-24T10:39:09+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-09-24T09:01:31+00:00 urn:sha1:173528aef50a4b452acdd8ec9aff13f25c3e092c Thanks to a new feature in libweb, it is now possible to generate HTTP responses asynchronously i.e., without blocking other clients if the response takes a long time to generate. This now allow users to search for files or directories without blocking other users, regardless how much time the search operation takes. This required cftw to deviate from the POSIX-like, blocking interface it had so far, and has been replaced now with a non-blocking interface, so that directories are inspected one entry at a time.