This line is so long, that the end is usually not visible on
the terminal. The dot looks out of place, and dropping it saves one
column for more interesting content.
When looking at logs from a boot with an encrypted device, I see
(with unrelevant messages snipped):
[ 2.751692] systemd[1]: Started Dispatch Password Requests to Console.
[ 7.929199] systemd-cryptsetup[258]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/2d9b648a-15b1-4204-988b-ec085089f8ce.
[ 9.499483] systemd[1]: Finished Cryptography Setup for luks-2d9b648a-15b1-4204-988b-ec085089f8ce.
There is a hug gap in timing without any explanatory message. If I didn't type
in the password, there would be no way to figure out why things blocked from
this log, so let's log something to the log too.
0cf8469387 added --console.
6af621248f added an optional argument, but didn't
update the help texts.
Note that there is no ambiguity with the optional argument because no positional
arguments are allowed.
Let's show the touch emoji whenever the user is likely going to have to
interact with the security token. We had this at many but not all such
messages. Let's add it everywhere.
Also, upgrade all messages where the user is supposed to do something to
LOG_NOTICE. Previously some where at LOG_NOTICE and others at LOG_INFO.
These messages are more than informational after all, they require user
action, hence deserve the higher prio, in particular as that formats
them bold with our usual log coloring.
Always use the word "test" in log messages, instead of "check".
Finally, always use the same wording: "confirm presence on security
token" for "up" and "verify user on security token" for "uv"
Let's improve compatibility with systemd 248 enrollments of FIDO2 keys:
if we have no information about the up/uv/pin settings, let's try to
determine them automatically, i.e. use up and pin if needed.
This only has an effect on LUKS2 volumes where a FIDO2 key was enrolled
with systemd 248 and thus the JSON data lacks the up/uv/pin fields. It
also matters if the user configured FIDO2 parameters explicitly via
crypttab options, so that the JSON data is not used.
For newer enrollments we'll stick to the explicit settings, as that's
generally much safer and robust.
We need really need to trust the feature set, since we are about to set
it in stone storing the result in JSON, hence react a bit more allergic
about token that misadvertise the feature.
Note that I added this to be defensive, I am not aware any token that
actually misadvertises this. hence it should be safe to make this fatal,
and should this not work we can always revisit things.
Let's try to handle keys gracefully that do not implement all features
we ask for: simply turn the feature off, and continue.
This is in particular relevant since we enroll with PIN and UP by
default, and on devices that don't support that we should just work.
Replaces: #18509
This makes the functions handle "xx/" and "xx/." as equivalent.
Moreover, now path_extract_directory() returns normalized path, that is
no redundant "/" or "/./" are contained.
This also makes path_compare() may return arbitrary integer as it now
simply pass the result of strcmp() or memcmp().
This changes the behavior of path_extract_filename/directory() when
e.g. "/." or "/./" are input. But the change should be desired.
without waiting for online, there is a race condition between systemd-networkd
actually setting the new values and the test checking those values
This also sets the link down before restarting systemd-networkd, to avoid
the wait for online being a no-op
In commit d895e10a a test was introduced to validate that prefix is a
child of rootprefix. However, it only works when rootprefix is "/".
Since the test is ignored when rootprefix is equal to prefix, this is
only noticed if specifying both -Drootprefix= and -Dprefix=, e.g.:
$ meson foo -Drootprefix=/foo -Dprefix=/foo/bar
meson.build:111:8: ERROR: Problem encountered: Prefix is not below
root prefix (now rootprefix=/foo prefix=/foo/bar)