[fprint] libfprint suggestions

[Daniel Drake]

Diego Zuccato wrote:
> Just a bunch of suggestions to improve libfprint (I could work on some, 
> if someone is interested):
> 1) abstract the enrolled prints provider from the other code, so that 
> other providers could easily be added (database, smartcard, 
> authentication server and so on) and print templates have not to reside 
> in (low-security) users' home dir. IIUC it's even already partially 
> doable if the user app saves fp_enroll_data, but that data is saved in 
> users' home anyway and there's no way to provide it for verify...

There are 2 storage mechanisms. The simple one saves it in the home 
directory, the more advanced one gives you a binary blob that you can 
save wherever you want.

pam_fprint uses the simple mechanism, but pam_fprint really is a very 
quick proof of concept that I wrote in about 15 minutes (most of the 
time spent learning about PAM). It has numerous issues and doesn't work 
with many apps (because those apps expect password input and break with 
anything else), but is OK as a quick proof of concept.

The "real" solution we're working towards is creating a D-Bus daemon 
(fprintd) with pluggable storage backends, and then integrating apps 
directly with that D-Bus API (bypassing PAM).

> 3) add fp_print_to_string or public array finger_names to avoid 
> replicating in every client. Could be interesting i18n support

I avoided it this far in order to keep clear of i18n stuff.

> 4) isn't it dangerous to call usb_init twice (if an app already uses 
> libusb and then calls fp_init) ? If it is, should it be checked in 
> fp_init or usb_init ?

The library should support being initialized twice and should have a 
concept of sessions/contexts so that one context does not interfere with 
another even when libfprint is being used twice in the same app. 
libusb-1.0 implements this. 
http://libusb.sourceforge.net/api-1.0/contexts.html
(libfprint has many other rough edges too, we have work to be done)

Thanks,
Daniel