The new conditoins are placed inside of services, but they cannot be
used to test service creds, but only system creds. This deserves
explicit mention, since it might be confusing otherwise.
Reverts a small part of 02380e1946
In particular, 'system/service credentials' are now described as simply
'credentials'. The selling point of credentials is that they are transparently
propagated from the system to services, so distinguishing between system and
service credentials is not important.
The description of ordering against initrd-switch-root.target is completely
rewritten. The old description was confused.
I think the description of systemd-measure should be reworked to clearly
describe what new functionality is provided and what policy changes are
built on top. But I don't qrok the details, so I left this part unchanged.
Some NEWS entries are tweaked a bit to address complaints about readability
from users.
"udev" is pronounced as /ˈjuːdɛv/, like in "user", hence "a" not "an".
Many distributions ship systemd-networkd as a separate file so we
need to be able to ship the tmpfiles networkd entries as part of
that separate networkd package. Let's split the networkd entries
into a separate file to make that possible.
%R is already used in service manager specifier expansion (cgroup root),
hence use a different char, that was so far not used.
Follow-up for: 6ceb0a4094
Let's be more precise here. Otherwise people might think this describes
the software system or so. We already expose this via hostnamed as
HardwareVendor/HardwareModel hence use the exact same wording.
(Note that the relevant props on the dmi device are just VENDOR/MODEL,
but that's OK given that DMI really is about hardware anyway,
unconditionally, hence no chance of confusion there.)
Follow-up for 4fc7e4f374
The old text was simply wrong, we used to read $layout from
/etc/kernel/install.conf and the machine ID from
$KERNEL_INSTALL_MACHINE_ID from /etc/machine-info. Correct that.
Apparently KERNEL_INSTALL_MACHINE_ID was already known back in v235
times, hence don't mention it anymore.
it's kinda weird retro-fixing these NEWS entries, given we deprecate
them again, but I couldn't let this really incorrect stuff be.
Conceptually the feature is great and should exist, but in its current
form should be worked to be generic (i.e. not specific to
Windows/Bitlocker, but appliable to any boot entry), not be global (but
be a per-entry thing), not require a BootXXXX entry to exist, and not
check for the BitLocker signature (as TPMs are not just used for
BitLocker).
Since we want to get 251 released, mark it in the documentation, in NEWS
and in code as experimental and make clear it will be reworked in a
future release. Also, make it opt-in to make it less likely people come
to rely on it without reading up on it, and understanding that it will
likely change sooner or later.
Follow-up for: #22043
See: #22390
/dev/urandom is seeded with RDRAND. Calling genuine_random_bytes(...,
..., 0) will use /dev/urandom as a last resort. Hence, we gain nothing
here by having our own RDRAND wrapper, because /dev/urandom already is
based on RDRAND output, even before /dev/urandom has fully initialized.
Furthermore, RDRAND is not actually fast! And on each successive
generation of new x86 CPUs, from both AMD and Intel, it just gets
slower.
This commit simplifies things by just using /dev/urandom in cases where
we before might use RDRAND, since /dev/urandom will always have RDRAND
mixed in as part of it.
And above where I say "/dev/urandom", what I actually mean is
GRND_INSECURE, which is the same thing but won't generate warnings in
dmesg.
All those pages contain a redirect at the top of the page, so it doesn't
make much sense to tell people to take the detour. Linking directly will
also increase the search rankings of the new pages.
If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it
over the machine ID from /etc/machine-id. If a machine ID is defined in
neither /etc/machine-info nor in /etc/machine-id, generate a new UUID
and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID
and use it as the machine ID if writing it to /etc/machine-info succeeds.
In practice, this means we have a more robust fallback if there's no
machine ID in /etc/machine-id than just using "Default" and allows
image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID
by simply writing it to /etc/machine-info themselves.
