This API was added to libfprint to allow drivers to report the match
result early before the operation has been completed. No driver makes
use of this facility yet and instead drivers try to finish the
operation early for quick result reporting. This primarily means not
waiting for finger removal.
Once drivers are updated, fprintd reactivity will regress unless the
early match callback is implemented as they would only get an operation
finished callback when the whole of the operation was finished,
including finger removal and finishing up USB communications.
See: https://gitlab.freedesktop.org/libfprint/fprintd/issues/35
Some devices require storing the print on the device, to support this,
try deleting prints from the device before deleting them from local
storage.
To handle these devices, add a new API that requires the device to be
claimed rather than allowing deletion without claiming the device first.
Also add appropriate fallbacks so that the old API will continue to
work, but warn about its use.
The new libfprint version has support for devices that store data on the
sensor. In that case, the on-sensor storage might fill up when the user
tries to enroll a new print.
The strategy introduced here to handle this is to try and delete prints
from the device that we do not know about (assuming, it is e.g. from an
old installation and unusable).
It can also happen that we are not able to garbage collect old prints.
If that happens, a new error code "enroll-data-full" will be returned
signalling the situation to the enrolling application.
fprintd's API docs say that "retry" errors for verification
"the verification is still ongoing" and that "[the] user should retry
scanning their finger.
Unfortunately, retry errors are fatal in libfprint. Make fprintd restart
operations when "retry" is the error for either identification or
verification purposes.
We need to also make sure that a "*Stop" D-Bus call will return as
normal if called while we're stopping a verification or identification
in order to restart it.
Closes: #22
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
Pretty hacky way to detect whether the device we're handling has
been disconnected during a verify or enrollment. This should allow
us to avoid users having to wait when somebody pulls the plug.
- Use D-Bus native properties instead of a GetProperties call.
- Fix a number of front-ends by registering the right signals and
marshallers following the "done" signal argument addition
- Fix VerifyStart call in the pam module
This is a gross hack for PAM sessions to work as expected. root
is allowed to verify any users. If you want to allow any other
actions for root, you'll need to go through normal PolicyKit
procedures.
This should fix fingerprint authentication not working in GDM, or
on the console.
Track clients connected to each device using EggDbusMonitor.
When there are no more clients connected to the device, release it.
When no devices are used anymore, set up a timeout to exit within
30 seconds.
Track the current action happening in the device, so we can
see what each device is doing. Refuse to launch a verification if
there's already one in progress.
If the finger passed for verification is -1, always emit the
VerifyFingerSelected signal, as the front-end isn't to know
whether we're using identification or verification.
- Add a finger selected signal, so that when an "automatic" finger
is selected for verification, we know which one to scan
- Fix the finger print numbers list to use GPOINTER_TO_INT /
GINT_TO_POINTER
- Make sure the gallery is NULL when there's no prints available
- Don't use identification when a finger number is provided
- Add support for selecting the finger number in verify
- Add support for fatal warnings there as well
Passing -1 to the VerifyStart function will either accept any
fingers scanned, if the driver supports identification, or select
the first enrolled fingerprint for scanning if it doesn't.
- Remove SetUsername itself, and add a username parameter to DeviceClaim,
ListEnrolledFingers and DeleteEnrolledFingers.
- For each of those calls, check that the incoming connection is allowed
to operate on that particular username
- Don't require a claimed device to list or remove fingerprints
- Clean up username and sender when releasing the device
- Modify the storage backend to not require an opened device to list
or delete fingerprints
- Add a simple test program to list registered fingerprints for the
usernames passed as argument
To delete all the enrolled finger prints for a particular user.
We can already overwrite existing enrolled fingerprints, and there's
not really any point in dismissing just one fingerprint.
