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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We already have specifiers that resolve to $XDG_STATE_HOME, and
$XDG_CONFIG_HOME. $XDG_DATA_HOME is in a similar vein.
It allows units belonging to the user service manager to correctly look
into ~/.local/share. I imagine this would be most useful inside of
condition checks (i.e. only run a service on session startup if some
data is not found in ~/.local/share) or in the inotify monitoring of a
.path unit
cryptenroll accepts only PKCS#11 URIs that match both a certificate and a private key in a token.
This patch allows users to provide a PKCS#11 URI that points to a certificate only, and makes possible to use output of some PKCS#11 tools directly.
Internally the patch changes 'type=cert' in the provided PKCS#11 URI to 'type=private' before storing in a LUKS2 header.
Fixes: #23479
Follow-up for b732606950 and
6706ce2fd2.
If Network.ignore_carrier_loss_set flag is set, then the timeout value
is always used, hence the logic implemented by
b732606950 never worked.
Fix the path for the generated.pcrlock files for the cmdline and initrd
cases. Without it the tool complains with:
Failed to parse component file /var/lib/pcrlock.d/720-kernel-initrd.pcrlock, ignoring: Is a directory
Signed-off-by: Alberto Planas <aplanas@suse.com>
This is what it is after all: encryption with a NULL key. This is more
descriptive, but also relevant since we want to use this kind of
credentials in a different context soon: for carrying pcrlock data into
a UKI. In that case we don#t want encryption, since the pcrlock data is
intended to help unlocking secrets, hence should not be a secret itself.
This only changes the code labels and the way this is labelled in the
output. We retain compat with the old name.
The same check is done exactly one line later, because this is one of
the things that json_variant_is_regular() checks.
As per: fa9a6db478 (r1441792019)
Otherwise we'd use some garbage value in the error path.
../src/resolve/resolved-dns-query.c: In function ‘dns_query_accept’:
../src/resolve/resolved-dns-query.c:944:27: error: ‘r’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
944 | q->answer_errno = -r;
| ^~
cc1: all warnings being treated as errors
Follow-up for 9ca133e97a.
If a binary built with ASan crashes for a reason unrelated to ASan
stuff, we're left with pretty much nothing, as there is neither an ASan
trace nor a coredump. Let's make this slightly more debug-able by
allowing such binaries to dump a core, but without the huge shadow map
(we should be actually fine by just setting disable_coredump=0, since
use_madv_dontdump defaults to true, but let's play it safe and not
potentially dump a 16+ TB core file).
statx_timestamp is, for all intents and purposes, the same as a struct
timespec. So, we can trivially convert it and call timespec_load on it.
This commit adds helper functions that do just that.
All the keys are high-entropy keys that cannot be practically
bruteforced and thus don't require protection from dictionary attacks.
With the exception of PINs, of course, which are low-entropy and user
provided.
Note that a new enrollment is required for unlocking while in DA
lockdown to function. Existing enrollments are subject to DA lockout.
Fixes: #30330
Let's add an explicit session class "user-early" for this, so that
change of behaviour on logind is primarily bound to the "class"
property, and not some explicit root checks. This has the benefit that
we can be more fine grained with implying this class: only do so for tty
sessions, not others.
Otherwise things might be weird, because background sessions might
become "idle", wich doesn#t really make much sense.
This shouldn't change much in 99% of the cases, but slightly corrects
behaviour as it ensures only "primary"/"foreground" sessions get the
idle logic, i.e. where a user exists that could actually make it
non-idle.
If we allow the timer accuracy to grow larger then the timeout itself
things are very confusing, because people might set a 1s time-out and we
turn that into 30s.
Hence, let's just cut off the 30s accuracy to the time-out itself, so
that we stay close to what users configured.
