Small and lightweight cloud storage written in C99 and POSIX.1-2008. https://gitea.privatedns.org/xavi/slcl/atom?h=master 2025-10-08T20:55:44+00:00 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 2024-06-12T15:11:17+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2024-06-12T15:09:43+00:00 urn:sha1:2d6fc0f9a6a60bc96ef9c4a10e450ed6a8247435 When no quota is entered, printf(1) could fail because '%d' would expect at least one argument. Whereas some printf(1) implementations, such as the one by GNU coreutils, are somewhat tolerant, stricter implementations such as Busybox would (correctly) refuse this. 2024-02-20T20:44:53+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2024-02-20T20:44:04+00:00 urn:sha1:dd29f9096a2e364db316a8975e5f6be5a9a97023 Otherwise, it would not be possible to replace user credentials if the directory already exists. 2024-01-26T19:32:28+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2024-01-26T19:32:28+00:00 urn:sha1:6d6c350479685da0310b11037b9b680242120923 For longer passwords, od(1) might introduce a newline character, causing printf(1) to interpret its input string incorrectly. 2023-10-19T15:35:39+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-10-19T13:44:06+00:00 urn:sha1:fc3db3927747fc98fb1378f46f232ef932b773e0 No changes must be committed to the database if mkdir(1) fails. 2023-10-19T15:35:38+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-10-19T13:34:24+00:00 urn:sha1:8b24f8dcbbee5e888a32044c9c06eb4eff690a0e Despite common use in several POSIX operating systems, mktemp(1) is not defined by POSIX.1-2008, nor even POSIX.1-2017. As long as it is not introduced, m4(1)'s mkstemp can be used with similar effect. 2023-09-15T23:00:14+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-15T22:57:34+00:00 urn:sha1:bec528a979ccadbd6687ee6679cf4b43771db586 sha256sum(1) is a GNU utility that might not be available under some POSIX systems. Since OpenSSL is already a dependency, it makes sense to reuse it to generate SHA256 digests. 2023-09-15T23:00:05+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-15T22:28:19+00:00 urn:sha1:18bd0d83bec9fe636446b994553dc2fa99dd0530 xxd(1) is closely related to vim(1), might not be available under some POSIX systems. 2023-09-15T22:59:46+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-15T22:40:22+00:00 urn:sha1:d8f683d9ca604f6a0cd04a42738e55f77a89f06e 2023-05-28T10:07:37+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-05-28T10:07:22+00:00 urn:sha1:20afa79038ec04e8a222d384410efec74ac40931