| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
This new application runs separately from slcl and communicates with it
via a named pipe. When files are added/removed to/from the user
directory, slcl shall write to the named pipe.
Then, this new tool shall process incoming entries and generate
or remove thumbnails accordingly. Such thumbnails are stored into a new
directory inside the database directory, namely thumbnails/, which
replicates the same structure as user/.
|
| | |
|
| |
|
|
|
| |
Future commits might introduce Makefiles on other directories that
should not be ignored.
|
| | |
|
| |
|
