This was forgotten after the last string changes in commit b483edbe.
Co-authored-by: Thibault HEINRICH <thibault.heinrich@ac-nancy-metz.fr>
Fixes: #123
PrivateNetwork=true is a bad idea, as it means that udev events cannot
be delivered. Remove it, we already restrict the address families
sufficiently anyway.
Closes: #119
This was never really used and it's breaking meson 60.
While this may just become a warning in 60.1, it's just better to avoid
using it.
See: https://github.com/mesonbuild/meson/issues/9441
Currently translated at 100.0% (60 of 60 strings)
Co-authored-by: Pavel Borecki <pavel.borecki@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: https://translate.fedoraproject.org/projects/fprintd/fprintd/cs/
Translation: fprintd/fprintd
Currently translated at 100.0% (60 of 60 strings)
Translated using Weblate (Marathi)
Currently translated at 5.0% (3 of 60 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: girish joshi <girish946@gmail.com>
Translate-URL: https://translate.fedoraproject.org/projects/fprintd/fprintd/mr/
Translation: fprintd/fprintd
If the user specified "any" finger, then we would mirror this back even
if there is only one finger available. Change it so that we act as if
that finger was passed explicitly, meaning we use the "verify" method
and also send the signal for the selected finger accordingly.
While the delay inhibitor is grabbed almost immediately, this can be
slow enough to not have happened immediately after the bus name has been
registered. Add a generous timeout to prevent issues.
If a print we have stored locally is not available in device anymore, we
need to cleanup the local database.
We do not get a proper DATA_NOT_FOUND error for most devices (indeed, at
this point no device does this properly). As such, do this when we see a
DATA_NOT_FOUND error and the first time that we get a verify-no-match
results on a device which is capable of listing all known prints.
Co-Authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
In case we got a data-not-found error, it means that the device has not
such prints stored, and thus the verification failed, and there's no
need to expose the internal reasons to fprintd clients.
If the client disconnected while the release call was stopping the
current action, then the disconnect will be processed. This means that
the device can be closed already and the session is destroyed.
Add a check for this, in the same way that the vanished handler deals
with this corner case.
This renames the internal "in-use" property to "busy" and redefines the
value to be TRUE either if a client is connected or if the device is
considered WARM or HOT.
This prevents fprintd shutdown while devices are warm in order to ensure
that the libfprint hardware protection is functional.
For verify-match, the PAM module should simply drop off the bus. In
other cases it should correctly run VerifyStop and Release the device.
Verify this for verify-match and verify-no-match.
In the verify-match case, this means disconnecting from the bus rather
than stopping the verification. This is the only way to make sure that
the result is immediately reported and we do not wait for the device to
be idle again (which generally means waiting for finger removal).
In the verify-no-match case we simply send the string first before the
operation is stopped. An exceeded retry limit is only reported after
VerifyStop has finished.
Before VerifyStart can be called again the current verify operation
needs to be completed. This requires waiting for VerifyStop to happen.
As such, remove the test, which is expected to fail randomly.
We just need large enough samples to tell them apart correctly. For this
a 128x128 area from the center of each image is sufficient.
This speeds up the test run considerably. Other ways of achieving this
could be to also lower the number of enroll steps for the image device.
The test suite ran into a very rare error where it seemed to get stuck
during authorization. A possible explanation is that the priv->_session
pointer re-fetching is optimized away and the pointer just continues to
contain the invalid placeholder rather than an updated value.
Use g_atomic_pointer_get in order to avoid this possibility entirely.
