| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
When a configuration is changed from the top-level directory, it should
be reflected on the subprojects as well.
Note: still, "make clean" is required so that the objects are built with
the new configuration flags.
|
| |
|
|
|
| |
Traditionally, this flag is set by users via the CFLAGS environment
variable, rather than including it by default.
|
| |
|
|
|
|
|
|
|
| |
Ideally, these flags must be appended to those introduced by the project
(e.g.: if user enters -Oz as CFLAGS, then -O1 and -Oz would co-exist and
the compiler would choose the later), rather than replacing them.
Additionally, user CFLAGS/LDFLAGS should be passed to children projects,
too.
|
| |
|
|
|
|
|
|
|
| |
The thumbnail subproject has dependencies against dynstr and
ImageMagick6, which might or might not be available on the system, or
might have been installed to non-standard paths.
Therefore, it is more robust to rely on a configure script that checks
whether the packages are available and how to deal with CFLAGS/LDFLAGS.
|
| | |
|
| |
|
|
|
|
|
|
| |
Otherwise, compilation could fail because zlib's header files and/or
library cannot be found on the system.
Additionally, since fdzipstream depends on zlib, zlib's ldflags must be
appended to those from fdzipstream, rather than hardcoding -lz.
|
| |
|
|
|
|
|
|
| |
Otherwise, compilation could fail because libcjson's header files
and/or library cannot be found on the system.
Additionally, -lcjson should not be hardcoded to the ldflags, as this
is better handled by pkg-config(1).
|
| |
|
|
|
|
|
| |
libweb has introduced several breaking changes:
- Add optional expiration date to http_cookie_create
- Replace Makefile with configure script
|
| |
|
|
|
| |
Otherwise, usergen(1) would be built without linking against libsodium,
and thus would fail to build.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
