Fix a possible crash when an fprintd client disappears. If the client
requested for the device to be released, then, without waiting for the
reply of that release, disappeared from the bus, we would try to close
it a second time, accessing a function pointer that didn't exist
anymore.
See https://bugzilla.redhat.com/show_bug.cgi?id=1515720
If not all the functions in the header are used, we'd get warnings about
them being unused. Mark all the functions as unused, so we can avoid
warnings.
Before claiming the device and therefore potentially activating
the actual hardware, make a call to see if the user has any
prints registered at all.
https://bugs.freedesktop.org/show_bug.cgi?id=99811
For some operations, i.e. listing the enrolled prints, the device
does not need to be claimed. Therefore the claiming can be delayed
until we actually start the verification process, allowing us to
query the fingerprint system if the user has any prints enrolled.
https://bugs.freedesktop.org/show_bug.cgi?id=99811
Give read-write access to USB devices in /dev, and the location of the
fingerprints, access to Unix sockets for D-Bus and
close everything else down.
See systemd.exec(5) for details about the options.
tx supports a single "--root" argument to pass both where it expects to
read the created data file (the .pot file) and the configuration. As
those are two separate directories with builddir != srcdir, copy the .tx
file from srcdir to builddir to upload the updated .pot file.
In file included from tests/enroll.c:29:0:
pam/fingerprint-strings.h: In function ‘finger_str_to_msg’:
pam/fingerprint-strings.h:99:6: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
return g_strdup_printf (TR (fingers[i].place_str_specific), driver_name);
^~~~~~
pam/fingerprint-strings.h:104:6: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
return g_strdup_printf (TR (fingers[i].swipe_str_specific), driver_name);
^~~~~~
This happens on hardware without fingerprint readers on every boot; we
don't need to log anything about it, it's totally normal.
This patch is part of an initiative to reduce logging spew in GNOME
so that actual errors and important messages are more visible.
https://bugs.freedesktop.org/show_bug.cgi?id=71889
