In both cases, the json string is short, so we can print it, which is useful
for diagnosing invalid data in packages. But we need escape non-printable
characters.
https://bugzilla.redhat.com/show_bug.cgi?id=2152685
I went over the rest of the codebase, and it seems that other calls to
json_parse() don't have this problem.
These are only needed for some kernel selftests but they prevent
building the mkosi image on aarch64 systems so let's drop them
until mkosi has support for conditional configuration so we can
only add these packages on the right architecture.
This improves the performance of parsing the file and reduces memory pressure.
Running 'fuzz-etc-hosts timeout-strv' with valgrind,
Before:
total heap usage: 321,020 allocs, 321,020 frees, 15,820,387,193 bytes allocated
real 0m23.531s
user 0m21.458s
sys 0m1.961s
After:
total heap usage: 112,408 allocs, 112,408 frees, 7,297,480 bytes allocated
real 0m8.664s
user 0m8.545s
sys 0m0.065s
Hopefully fixes oss-fuzz#47708 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47708).
After #25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.
Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.
Fixes#19208.
This solves Debian Bug report 1008760:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008760.
Solution was inspired by this kernel bug report message:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c15.
My measured pad dimensions with a ruler were 85x44mm.
But I decided to take the 2x size reported by the current kernel
when invoking the touchpad-edge-detector command from the
libdev-tools package. Because this comment claims that the old
vs new kernel reportings differ by factor 2:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c3 .
Therefore I have used this command to get the new entry to 60-evdev.hwdb:
"root@pb:~# touchpad-edge-detector 80x34 /dev/input/event2
Touchpad ETPS/2 Elantech Touchpad on /dev/input/event2
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..1254], y [0..528]
Touchpad sends: x [0..2472], y [-524..528] -^C
Touchpad size as listed by the kernel: 40x17mm
User-specified touchpad size: 80x34mm
Calculated ranges: 2472/1052
Suggested udev rule:
# <Laptop model description goes here>
evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnPackardBell:bvrV1.21:bd08/09/2012:br21.240:svnPackardBell:pnEasyNoteTS11HR:pvrV1.21:rvnPackardBell:rnSJV50_HR:rvrBaseBoardVersion:cvnPackardBell:ct10:cvrV1.21:*
EVDEV_ABS_00=0:2472:31
EVDEV_ABS_01=-524:528:31
EVDEV_ABS_35=0:2472:31
EVDEV_ABS_36=-524:528:31
"
This tool was "deprecated" back in 65eb4378c3,
but only by removing documentation. This is somewhat surprising, but udevadm
hwdb --update and systemd-hwdb update generate different databases. udevadm
runs in compat mode and (as far as I have been able to figure out from a quick
look), it omits filename information and does some other changes to the
datastructures. The consuming code (udev) is the same in both cases, so this
"compatibility mode" seems very strange. But I don't think it's worth trying to
figure out why things were done this way. Let's just push people towards the
new code.
Inspired by https://github.com/systemd/systemd/issues/25698#issuecomment-1346298094.
And drop to mention sd_id128_get_boot_app_specific() may return -ENOENT
or -ENOMEDIUM. The function does not read /etc/machine-id. But reads a
file in the procfs, which is a kind of the kernel API. Hence the
failures are caused only when the system has wrong setup.
We would execute up to four hwdb match patterns (+ the keyboard builtin):
After the first hit, we would skip the other patterns, because of the GOTO="evdev_end"
action.
57bb707d48 (rules: Add extended evdev/input match
rules for event nodes with the same name), added an additional match with
":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user
hwdb patterns, because we quit after the first match.
In general hwdb properties are "additive". We often have a general rule that
matches a wider class and then some specific overrides. E.g. in this particular
case, we have a match for all trackpoints, and then a bunch of model-specific
settings.
So let's change the rules to try all the match patterns and combine the
received properties. We execute builtin-keyboard once at the end, if there was
at least one match.
Fixes#25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226.
This also impacts other cases which I think would be very confusing for users.
Since we quit after a first successful match, if we had e.g. a match for
'evdev:input:b*v*p*' in out database, and the user added a match using
'evdev:name:*', which is the approach we document in the .hwdb files and which
users quite often use, it would be silently ignored. What's worse, if we added
our 'evdev:input:b*v*p*' match at a later point, user's match would stop
working. If we combine all the properties, we get more stable behaviour.
If an attribute is read but the value is not used (i.e. ret_value is NULL),
then sd_device_get_sysattr_value() mistakenly frees the read data even though
it is cached internally.
Fixes a bug introduced by acfc2a1d15.
Fixes#25702.
`fido2_is_cred_in_specific_token()` should simply not return error codes
for non-fatal errors. For example, `-ENODEV` can be safely translated to
a `false` return value. When the pre-flight request is not supported, we
should simply return true to instruct the caller to attempt to use the
device anyway.
All error codes returned by the funtion should now be fatal and logged
at error level. Non-fatal errors should only appear in debug logs.
This prevents unnecessary user interactions when `fido2-device` is set to
something other than `auto` -- a case overlooked in the original PR #23577
(and later #25268).
We do not move pre-flight checks to `fido2_use_hmac_hash_specific_token`
because the behaviors are different between different cases: when the
device path is NULL, we try to automatically choose the correct device,
in which case pre-flight errors should be "soft" errors, without
spamming the tty with error outputs; but when a specific device path is
given, a pre-flight request that determined the non-existence of the
credential should be treated the same as a failed assertion request.
According to the FIDO2 spec, tokens may not support pre-flight checks
for credentials requiring UV, at least not without at least
`pinUvAuthParam` or `uv = true`. Originally, in #25268, this was
handled by passing a PIN to satisfy `pinUvAuthParams`, but this is not
ideal, since `pinUvAuthParam` can be obtained from either a PIN
or a UV verification. Forcing the user to enter the PIN here (which is
often just the fallback option on UV devices) is no better than just
trying out each device with the actual assertion request.
As a result, this commit disables pre-flight checks when the credential
requires UV, and instead reverts to the old behavior (trying out each
device and each key slot, requiring multiple user interactions) for this
type of credentials.
