- 03 Nov, 2008 3 commits
-
-
Daniel Drake authored
-
Otherwise it just won't work...
-
Add a PAM module, and enable all the warnings
-
- 02 Nov, 2008 21 commits
-
-
..
-
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.
-
More warnings fixed in the file storage.
-
More to do though...
-
This is better than what we've got currently, and even works with older versions of GCC.
-
- 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.
-
ClaimDevice is now only needed for hardware related actions
-
Remove a few debug messages, and merge another one.
-
- 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
-
Add naive plugin support to the storage code, it will load plugins from $(libdir)/fprintd/modules, given the configuration from /etc/fprintd.conf.
-
This should be used to set the storage type.
-
We can only delete fingerprints if we could enroll them in the first place.
-
Allow enroll and verify to optionally set a username. Makes testing easier.
-
Add a few more TODO items
-
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.
-
Less implementation details, more use casing.
-
They were just doing nothing interesting for us, and might cause problems if data changes under us (say, remote storage).
-
Will be useful when people try to do crazy things with fprintd
-
..
-
0.8 is the minimum version required.
-
- 22 May, 2008 11 commits
-
-
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.
-
Get a PolicyKit context per-device, set up its main loop, and steal more code from gnome-panel to check whether the actions are allowed for a particular caller.
-
When the user claims the device, get its uid and username, and use this data to read/save from storage.
-
Save the fingerprint using the storage functions so we can verify the data we enroll.
-
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.
-
Fixes a few warnings on compilation
-
First FromStorage variant to go
-
Some thoughts on storage handling
-
We use the current user's username instead.
-
Async methods should return "out" variables using dbus_g_method_return(), not through function parameters. Fixes crashing using those functions.
-
Thanks to Richard Hughes for spotting this. Shouldn't make any operational differences, as the return values of those methods weren't used anyway.
-
- 18 May, 2008 1 commit
-
-
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
-
- 16 May, 2008 4 commits
-
-
When there are no errors on startup, we'd get a warning as we were copying a NULL GError
-
This makes debugging warnings from fprintd easier, uses GOption as available since glib 2.6
-
Fix wrong assumption of semantics when fp_discover_devs() returns NULL.
-
Simply missing a po/Makefile.in in the config output, oopsie
-
