IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For micmute userspace handles both micmute and f20, as Xorg cannot
handle the high keycode that the micmute key has. As such, adding the
remapping means that the key will work on Xorg clients and not just when
using wayland.
If SetCredential= and LoadCredentials= are combined for the same
credential name, then the former shall act as fallback for the latter in
case the source file does not exist. That's documented, but didn't work.
Let's fix that.
This was broken in 3989bdc1ad let's
restore the functionality.
Basically, we want that if a relative name is specified as source to
load from we take it relative to the credentials dir the service manager
itself got passed.
Given that the recusive credential loading allows two ways to load the
same credentials, it's important to define a clear order so that it is
always the same one that wins.
i.e. if you use LoadCredential=foobar:/tmp/xyz and there are two files
/tmp/xyz/abc/cde and /tmp/xyz/abc_cde these would both result in a
credential foobar_abc_cde being set, hence it is important to make clear
which one shall win, and that it is always the same one.
When checking whether we already loaded a credential before, let's just
use faccessat() in the credential dir we are populating. First of all,
we already do it exactly that way when appliying SetCredential= settings
later. Secondly, this is not performance relevant, and by using
faccessat() things simply become a lot simpler.
Given we only need a single field off the ExecLoadCredential structure
we don't have to link it as a whole, but just copy that one bit over
directly, simplifying the struct a bit.
recurse_dir() allows specifiying a freely choosable initial path to
which to append the subdirs as it descends into the tree. If we pass the
configured id there, recurse_dir() will suffix the subdir to that for
us, so that we don't have to do that manually anymore in the callback,
simplifying things a bit.
Let's just simplify the logic and pass the fields we need as regular
arguments, even if that means the function now has a lot. It's otherwise
really weird that we have to fake a local ExecLoadCredential from the
real one.
We recently added caching for the dependencies we build from source
in mkosi's github action which speeds up builds by +-10 minutes. Let's
update to the latest commit so we benefit from this in systemd's mkosi
CI as well.
We use authenticated encryption, and that deserves mention. This in
particular relevant as the fact they are authenticated makes the
credentials useful as initrd parameterization items.
LoadCredentials= in unit files supports a syntax passing a single string
only (in which case the credentials are propagated down from the host).
but systemd-run's --property= setting doesn't allow that yet. Fix that.
The overflow check for ref counting should not be subject to NDEBUG,
hence upgrade assert() → assert_se(). (The check for zero is an
immediate bug in our code, and should be impossible to trigger, hence
it's fine if the check is optimized away if people are crazy enough to
set NDEBUG, so that can stay assert())
https://github.com/systemd/systemd/pull/23099#discussion_r854341850
This is supposed to be useful when generating credentials for immutable
initrd environments, where it is is relevant to support credentials even
on systems lacking a TPM2 chip.
With this, if `systemd-creds encrypt --with-key=auto-initrd` is used a
credential will be encrypted/signed with the TPM2 if it is available and
recognized by the firmware. Otherwise it will be encrypted/signed with
the fixed empty key, thus providing no confidentiality or authenticity.
The idea is that distributions use this mode to generically create
credentials that are as locked down as possible on the specific
platform.
Previously, when encrypting creds you could pick which key to use for
this via a 128bit ID identifying the key type, and use an all zero ID
for rquesting automatic mode.
Let's change this to use an explicitly picked 128bit ID for automatic
mode, i.e. something other than all zeros. This is in preparation for
adding one further automatic mode with slightly different semantics.
no change in behaviour.
Note that the new 128bit id is never written to disk but only used
internally to indicate a specific case.
Sometimes it's useful from shell scripts to check if we have a working
TPM2 chip around. For example, when putting together encrypted
credentials for the initrd (after all: it might be wise to place the
root pw in a credential for the initrd to consume, but do so only if we
can lock it to the TPM2, and not otherwise, so that we risk nothing).
Hence, let's add a new "systemd-creds has-tpm2" verb: it returns zero if we
have a working TPM2 (which means: supported by kernel + firmware + us),
or non-zero otherwise. Also show which parts are available.
Use-case: in future the 'kernel-install' script should use this when
deciding whether to augment kernels with security sensitive credentials.
Let's improve the output regarding TPM2 support in "bootctl": let's show
whether we have local driver support and/or firmware support, and
colorize it.
(For now, don't show if we natively support TPM2, since the tool is
mostly bout boot time stuff, where it dosn't really matter much what we
do in userspace)
