Add a method to delete only a Fingerprint for a device, this is required
by they g-c-c UI design and at the same time it reflects the libfprint
API, where so far only a fingerprint at time can be deleted.
libfprint v1.90.4 introduced a new finger status API to expose to the UI
the finger status on sensor.
Add two new properties to the Device interface that represent the
possible values.
Add new tests.
Fprintd is dependent on the deprecated dbus-glib, also this doesn't provide
various features we can take advantage of, like the ones for async
authentication mechanism.
So, remove all the dbus-glib dependencies and simplify the code, but without
any further refactor, and keeping everything as it used to work, while this
will give room for further improvements in subsequent commits.
Internally, we just use dbus-codegen to generate the skeletons, and we
use the generated FprintdDBusManager with composition, while we
implement the device skeleton interface in FprintDevice, so that we
don't have to use it as a proxy, and keep being closer to what it used
to be with dbus-glib.
Fixes: #61
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.
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
- 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
- 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.
Add PolicyKit checks to all the public functions, grouped
in 2 main groups: Verify and Enroll
By default, only the user is able to enroll new fingers,
or verify themselves.
You need to be allowed at least one of those 2 actions
to be allowed to claim or release the device.
We also add a new SetUsername function, for administration
functions. Users will need to be authenticate as admins to
be allowed to change the username on which the actions will
be taken. Any prints loaded before the change of username will
be unloaded.
Last FromStorage variant killed, we need to make sure all
the functions now use the storage functions internally,
otherwise we won't be able to load from the place we save.
Mark all the methods on the device as async, so we
can get access to the associated DBusGMethodInvocation.
When claiming the device, remember the sender, and for every
API entry point, check that the sender is the same as the one
that made the original claim.
Trying to enroll a user whilst the device is already claimed
from another program will fail with:
** ERROR **: failed to claim device: Device was already claimed
This is the first step towards PolicyKit and multi-user support
