The upstream recommended minimum length for db_key_base is 30 bytes,
which our option descriptions repeated. Recently, however, upstream
has, in many places, moved to using aes-256-gcm, which requires a key
of exactly 32 bytes. To allow for shorter keys, the upstream code pads
the key in some places. However, in many others, it just truncates the
key if it's too long, leaving it too short if it was to begin
with. This adds a patch that fixes this and updates the descriptions
to recommend a key of at least 32 characters.
See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53602
This version contains a vulnerability[1], and isn't maintained. The
original reason to have two jellyfin versions was to allow end-users to
backup the database before the layout was upgraded, but these backups
should be done periodically.
[1]: <https://nvd.nist.gov/vuln/detail/CVE-2021-21402>
Current module add backups forever, with no way to prune old ones.
Add an option to remove backups after n full backups or after some
amount of time.
Also run duplicity cleanup to clean unused files in case some previous
backup was improperly interrupted.
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
The last bits to prevent babeld from running unprivileged was its
kernel_setup_interface routine, that wants to set per interface
rp_filter. This behaviour has been disabled in a patch that has been
submitted upstream at https://github.com/jech/babeld/pull/68 and reuses
the skip-kernel-setup config option.
→ Overall exposure level for babeld.service: 1.7 OK 🙂
some ban actions need additional packages (eg ipset). since actions can be
provided by the user we need something general that's easy to configure.
we could also enable ipset regardless of the actual configuration of the system
if the iptables firewall is in use (like sshguard does), but that seems very
clumsy and wouldn't easily solve the binary-not-found problems other actions may
also have.
it's not possible to set a different default maxretry value in the DEFAULT jail
because the module already does so. expose the maxretry option to the
configuration to remedy this. (we can't really remove it entirely because
fail2ban defaults to 5)
