The Xbox Wireless Headset does not get assigned a sound form factor
when connected via the dongle using the `xone` driver.
Add USB IDs for the old & new dongle and built-in variants.
Since we use varargs for sd_message_append() we need to make sure the
parameters we pass are actually 64bit wide, if "t" is used. Hence cast
appropriately if necessary.
I went through the whole tree, and in most cases we got it right, but
there are some cases we missed so far.
Inspired by: #31420
Apparently on HyperV the measurement logs announce the hash algs in a
different order in the header than the records have them. Let's handle
this gracefully
Otherwise weird stuff happens on the other side:
[1217111.957263] testsuite-46.sh[61]: + homectl create test-user --disk-size=min --luks-discard=yes --image-path=/home/test-user.home --luks-pbkdf-type=pbkdf2 --luks-pbkdf-time-cost=1ms
[1217112.598219] homectl[66]: Operation on home test-user failed: Provided flags are unsupported (0ad2578000000000).
(taken from TEST-46-HOME run on armv7l)
Fixes issue mentioned in https://github.com/systemd/systemd/pull/31419#issuecomment-1955117397.
Adds a SAFE_FD_FLAGS define to list out all the safe FD flags, and also
an UNSAFE_FD_FLAGS() macro to strip out the safe flags and leave only
the unsafe flags. This can be used to quickly check if any unsafe flags
are set and print them for diagnostic purposes
The command will refuse to write to a TTY, so give a strong hint
that redirecting to a file is recommended. This makes the synopsis,
man page text, and --help output consistent.
Also drop the space after the redirection operator everywhere.
This bool controls whether we should interactively ask for a password,
which is pretty much what the ask_password-api.c APIs are about. Hence,
just make the bool a flag in AskPasswordFlags enum, and use it
everywhere.
This still catches the flag early in upper levels of the codebase,
exactly as before, but if the flag is still present in the lower layers
it's also handled there and results in ENOEXEC if seen.
This is mostly an excercise in simplifying our ridiculously long
function call parameter lists a bit.
Let's bring the credentials into a better order, in order of relevance.
Also, let's clarify what the generic LUKS PIN is about.
Finally, list the credentials in system-credentials(7) too, after all
people might want to unlock a disk with this via SMBIOS Type 11 or so.
Let's make sure that when cryptenroll asks for the TPM2 or FIDO2 token
PIN it uses cryptenroll.* credential namespace, and cryptsetup uses
cryptsetup.*.
similar as the previous commit, let's clean up the credential name we
use. Use home.token-pin in case of homectl, and cryptenroll.pkcs11-pin
in case of cryptenroll.
The TPM2 enrollment is the only of the three token enrollments where the
user picks a PIN at enrollment time (the others have a PIN set for the
token, not for the enrollment). Let's make sure it uses a different
credential for retrieving this PIN, in order to make sure people can
programmatically change PINs via credentials (in which case they need to
supply both).
Querying a fido2 PIN via askpw for enrolling is currently used in two
places: cryptenroll and homectl. So far we sloppily used the same fixed
credential name "fido2-pin" in both cases. Let's tweak that and make the
credential name match the other credentials cryptenroll or home query,
i.e. using the cryptenroll.* and home.* namespaces.
This is particular done in light of #31370, which wants to make the
credential name public. We really should get the name in order before
making it public.
Let's drop the "systemd-" prefix from the credential name. We do not
prefix credentials that way so far. Don't do so here either.
The name is not really API, it's not documented, hence change it now
where we still can.
The "id" is used in the askpw protocol to recognize password prompts, in
case a service is replying to them and needs some id. Previously we set
an incorrect id, the one of cryptsetup. Fix that.
(I guess the id is not used much, it comes from a time where we had no
credentials, and thus some people wanted to supply passphrases
programmatically rather interactively. The usecase is probably gone, but
we should still set some valid id I guess.)
Rather than adding more and more parameters to ask_password_auto(), let's
pass a structure of the fields that often are constant anyway.
This way, callers can fill in what they need, and we take the filled
structure which we can pass around internally as one.
This is in particular preparation for adding one more field in one of
the next commits.