Hey, On Sun, 2008-07-13 at 10:43 -0500, Daniel Drake wrote: > 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).
As Daniel mentions, this is PAM's fault. I discussed that for a long period of time with colleagues (Jon McCann, who works on GDM and gnome-screensaver, and Ray Strode, who already implemented SmartCard login support in Fedora/RHEL), and the "solution" would be to use 2 (or more) PAM stacks. One for each hardware device that can log you in, and one for password authentication. I believe that Jon might even have something better. This doesn't affect the development right now though, we still have some way to go ;) > >> 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? I double/triple-checked the API, and it should be alright to use with PAM. We might need some extra work to be done to allow more flexible gallery identification (for use in medium-security point-of-sale setup). That's something I'll be working on soon, as I finally received my new hardware! > >> (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) Is that such a good idea? I'd rather we used it more, especially as we want developers to be using the fprintd D-Bus service in the future, which will be using glib in any case. What's the reasoning behind that? > - standardising error codes > - making driver inclusion configurable at configure-time (then > separating out dependencies by driver e.g. only aes4000 requires > ImageMagick) This should be pretty easy. See Totem's configure.in to select the plugins: http://svn.gnome.org/viewvc/totem/trunk/configure.in?view=markup Look for "Movie player plugins". Cheers _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
