xavi/slcl/auth.c, branch libweb-configureSmall and lightweight cloud storage written in C99 and POSIX.1-2008.
https://gitea.privatedns.org/xavi/slcl/atom?h=libweb-configure2026-02-13T06:55:07+00:00Bump libweb2026-02-13T06:55:07+00:00Xavier Del Campo Romeroxavi92@disroot.org2026-02-12T17:04:48+00:00urn:sha1:8479f8e7797b4b26230d50bde981ff4e3f520603
libweb has introduced several breaking changes:
- Add optional expiration date to http_cookie_create
- Replace Makefile with configure script
Replace OpenSSL with libsodium and argon2id2025-10-08T20:55:44+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-10-08T11:50:52+00:00urn: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
Fix wrong function names on failure2025-10-02T09:35:29+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-10-02T09:35:29+00:00urn:sha1:425a2e48c0f8266d5df0a1c2b40e3c176e40b283auth.c: Remove unused arguments2025-10-02T09:35:16+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-10-02T09:35:16+00:00urn:sha1:33c632d11ee9438bb1e25c5ba720c6cf6037fe27auth.c: Fix missing username check2025-10-02T09:32:02+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-10-02T09:32:02+00:00urn:sha1:4dcd4d47cc717b37844dbe7f01485f9a0662a964
So far, auth_login was looking for a key that matched the expected HMAC,
among all registered users, and therefore without looking up the
username from the cookie key.
This allowed attackers to forge a cookie with a valid key but another
username, and therefore see the contents from other users.
auth.c: Make use of crealpath2025-09-24T09:03:39+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-24T21:23:55+00:00urn:sha1:7e34b2d141858eeae3ffb9e514bd55a767a52492
crealpath already provides a mechanism to determine the current working
directory from getcwd(3).
auth.c: Replace sprintf(3) with snprintf(3)2024-08-21T21:47:17+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-08-21T21:47:17+00:00urn:sha1:d73097dd74625711dd02d5e3a6cb6bdca5ca8150
Even if this specific use of sprintf(3) was safe because sizeof
sha256_str > (sizeof sha256 * 2), some implementations would consider
sprintf(3) unsafe anyway.
auth.c: Reject empty files2024-06-13T06:25:29+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-06-13T06:25:29+00:00urn:sha1:37c4b2967863fe5ba265a7fefad60dbd96a09f17
It makes no sense to attempt to fopen(3) an empty file and malloc(3)
zero bytes so as to dump it, as dump_db is still meant to fail on empty
files.
auth.c: Fix potential signed integer overflow2023-10-14T11:08:25+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-10-14T11:05:58+00:00urn:sha1:d96e5685ee072d5fd80c562089c1080a53673187
For platforms where int is a 16-bit data type, this operation might
overflow and possibly cause either unexpected behaviour and/or a
compiler warning.
Therefore, it is safer to promote each integer constant accordingly.
Apply slweb renaming to libweb2023-10-10T22:08:40+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-10-10T21:43:47+00:00urn:sha1:28ae865e5ecad9b398ac21fa148fc4b93c987226