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-03T15:26:19+00:00 2026-02-03T15:26:19+00:00 Xavier Del Campo Romero xavi92@disroot.org 2026-02-03T15:25:10+00:00 urn:sha1:0aa3102b79e327a3fb7695ded258f0cec7ad93f4 Otherwise, usergen(1) would be built without linking against libsodium, and thus would fail to build. 2025-10-08T20:57:00+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-08T20:54:47+00:00 urn:sha1:8d8179d3b412cdd2c1af60539b9aec89631f3fe6 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:16+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-07T21:48:44+00:00 urn:sha1:055045e559ae98f4b9157970dae7ad74e6d45ff0 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-02T09:38:57+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-02T09:38:57+00:00 urn:sha1:eab87d6828f21d01dfd09bc01bf094ca5e176358 2025-09-24T09:03:39+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-07-24T21:17:48+00:00 urn:sha1:a74f4a72504d1c5923bd2b4e85941f34d9fce79f 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. 2024-01-26T19:31:18+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2024-01-26T19:30:52+00:00 urn:sha1:974d263b7e4776e9bad36adc2b611abfc6a34b1c 2023-11-24T00:52:52+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-11-24T00:52:52+00:00 urn:sha1:d9d1811f8922f0509d922943efb3c487ace3de9f slweb was renamed to libweb some time ago: commit 28ae865e5ecad9b398ac21fa148fc4b93c987226 Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com> Date: Tue Oct 10 23:43:47 2023 +0200 Apply slweb renaming to libweb 2023-10-25T20:13:23+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-10-15T23:20:49+00:00 urn:sha1:6fa38f4d83dfd67bba9ef49bb2d1ece3a57e95d1