[fprint] libfprint suggestions

[Daniel Drake]

Diego Zuccato wrote:
> Well, IMVHO it quite correctly follows the KISS paradigm. I don't think 
> it's really a good thing make it dependent on too many components...
> I'm using it w/ GDM and xlock w/o problems. The only bad thing is that 
> they ask a password anyway (but it can be empty). And the messages 
> appear in popup windows (have to click OK or press Enter).

Those are the kinds of problems we want to fix. Not to mention that 
there are numerous things that pam_fprint doesn't work with (some KDE 
stuff, gksu, gnome-screensaver, gnome-keyring, slim, ...)

There are other limitations too. PAM does not allow us to (neatly) have 
a "enter password or scan finger" authentication scenario. And there is 
no way we could do things like show visual scan feedback after a scan 
(which would help the user improve their scanning technique).

>> 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).
> That can be perfect for non-system auth (for example to unlock GPG 
> private key or replace Thunderbird's master password), but I wouldn't 
> recommend it for a PAM module to let users login.

Why not?

>> (libfprint has many other rough edges too, we have work to be done)
> Is there something a newbie like me could have a look at to help?

If you wanted to implement the session idea, you could look at how 
libusb-1.0 does it. Other good starter tasks that spring to mind are:
  - removing glib dependency (or at least making steps in that direction)
  - standardising error codes
  - making driver inclusion configurable at configure-time (then 
separating out dependencies by driver e.g. only aes4000 requires 
ImageMagick)

Daniel