From hadess at hadess.net Fri Dec 7 12:27:22 2018 From: hadess at hadess.net (Bastien Nocera) Date: Fri, 07 Dec 2018 13:27:22 +0100 Subject: [fprint] fprintd single sign on limitation In-Reply-To: <000001d47bbf$ae9b99b0$0bd2cd10$@emc.com.tw> References: <000201d47b1d$38262900$a8727b00$@emc.com.tw> <7d62fc0029963e2e0829e05f26577aa7f0d7d27f.camel@hadess.net> <000001d47bbf$ae9b99b0$0bd2cd10$@emc.com.tw> Message-ID: <8bc9212689f77cc5f3581a298bfd33ce1bf4e7b2.camel@hadess.net> Hello Dave, On Wed, 2018-11-14 at 10:13 +0800, Dave.Wang wrote: > Dear Bastien, > > Thanks for your quick reply! > > Feeling sorry for not indicating clearly about our definition of SSO > In our definition of SSO, What I was saying is that you shouldn't be using "SSO" as a name, it's already something that exists, and that is completely different from what you're describing below: https://en.wikipedia.org/wiki/Single_sign-on > 1. Our fingerprint sensor is located on power button of notebook > 2. Driver would inform device to pre-capture image while someone > touch the power button. > 3. In login phase, user wouldn't have to identify finger if the pre- > capture image is existed > 4. Driver would submit that pre-capture image to algorithm if the > pre-capture image is existed, and then login to its corresponding > account. I don't understand at which point the user-space driver would be able to tell the power button's IC to capture the image, or where that image would end up being stored. Would the driver tell that to the power button's IC/fingerprint reader before the machine gets turned off? > In your opinion, is it possible to implement SSO in libfprint? > Thank you very much for your time and suggestion! There are multiple steps to that, and the first one would be to extend fp_driver internally to allow setting that "remember fingerprint on next boot", as well as providing a way to extract the "remembered" fingerprint. After that, integration work into the OS can start. I think we would be taking cues from the smartcard integration done in gnome-settings- daemon[1] and integrate it in fprintd. Access to hardware and specs would be much appreciated if you want more help doing this integration. It's pretty difficult designing for a use case in a vacuum. I'd recommend looking into this once the work has been done in libfprint to support the hardware features. Cheers [1]: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/tree/master/plugins/smartcard From hadess at hadess.net Fri Dec 7 12:33:18 2018 From: hadess at hadess.net (Bastien Nocera) Date: Fri, 07 Dec 2018 13:33:18 +0100 Subject: [fprint] Artefacts in images from fprint-demo In-Reply-To: References: Message-ID: <11576296cec49d896b0f4b0d22192d0c10bc0907.camel@hadess.net> Hey Josh, On Thu, 2018-08-16 at 20:14 +0100, Josh Holland wrote: > Hi, > > I was trying out my fingerprint sensor (EgisTec ES603) with fprint- > demo, and I noticed that fairly often the image produced when > verifying is twice as tall as normal, and the bottom half contains > only some long vertical lines. Is this indicative of a problem with > my particular fingerprint sensor, or with fprint (and if so, is there > anything I can do to help debug it)? Is it likely to affect > fingerprint recognition? > > I'm using fprint from the Ubuntu Bionic repositories – apt reports > that fprintd is at version 0.8.0-2. Better late than never, I hope at least. This is likely a bug in the driver itself, though there were some bug fixes related to image manipulation in recent months. If you feel comfortable with it, you could test with the development version of libfprint, or wait until it gets updated. Cheers From ia.filatov at gmail.com Fri Dec 7 12:46:30 2018 From: ia.filatov at gmail.com (Igor Filatov) Date: Fri, 7 Dec 2018 14:46:30 +0200 Subject: [fprint] fprintd single sign on limitation In-Reply-To: <8bc9212689f77cc5f3581a298bfd33ce1bf4e7b2.camel@hadess.net> References: <000201d47b1d$38262900$a8727b00$@emc.com.tw> <7d62fc0029963e2e0829e05f26577aa7f0d7d27f.camel@hadess.net> <000001d47bbf$ae9b99b0$0bd2cd10$@emc.com.tw> <8bc9212689f77cc5f3581a298bfd33ce1bf4e7b2.camel@hadess.net> Message-ID: I think Dave means that the scanner would capture the print when the device is powered on. Not as instructed by a userspace driver, but as a "hardware feature" of the button/sensor itself. It would store a single image until asked by libfrint to perform a scan, at which point it would just submit the image it has. libfprint doesn't need to know. It only needs to match the print not aginst the library of a chosen user, but of all users and return a pair of (ok, user_id). On Fri, 7 Dec 2018, 14:36 Bastien Nocera, wrote: > Hello Dave, > > On Wed, 2018-11-14 at 10:13 +0800, Dave.Wang wrote: > > Dear Bastien, > > > > Thanks for your quick reply! > > > > Feeling sorry for not indicating clearly about our definition of SSO > > In our definition of SSO, > > What I was saying is that you shouldn't be using "SSO" as a name, it's > already something that exists, and that is completely different from > what you're describing below: > https://en.wikipedia.org/wiki/Single_sign-on > > > 1. Our fingerprint sensor is located on power button of notebook > > 2. Driver would inform device to pre-capture image while someone > > touch the power button. > > 3. In login phase, user wouldn't have to identify finger if the pre- > > capture image is existed > > 4. Driver would submit that pre-capture image to algorithm if the > > pre-capture image is existed, and then login to its corresponding > > account. > > I don't understand at which point the user-space driver would be able > to tell the power button's IC to capture the image, or where that image > would end up being stored. Would the driver tell that to the power > button's IC/fingerprint reader before the machine gets turned off? > > > In your opinion, is it possible to implement SSO in libfprint? > > Thank you very much for your time and suggestion! > > There are multiple steps to that, and the first one would be to extend > fp_driver internally to allow setting that "remember fingerprint on > next boot", as well as providing a way to extract the "remembered" > fingerprint. > > After that, integration work into the OS can start. I think we would be > taking cues from the smartcard integration done in gnome-settings- > daemon[1] and integrate it in fprintd. > > Access to hardware and specs would be much appreciated if you want more > help doing this integration. It's pretty difficult designing for a use > case in a vacuum. I'd recommend looking into this once the work has > been done in libfprint to support the hardware features. > > Cheers > > [1]: > https://gitlab.gnome.org/GNOME/gnome-settings-daemon/tree/master/plugins/smartcard > > _______________________________________________ > fprint mailing list > fprint at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/fprint > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hadess at hadess.net Fri Dec 7 13:26:40 2018 From: hadess at hadess.net (Bastien Nocera) Date: Fri, 07 Dec 2018 14:26:40 +0100 Subject: [fprint] fprintd single sign on limitation In-Reply-To: References: <000201d47b1d$38262900$a8727b00$@emc.com.tw> <7d62fc0029963e2e0829e05f26577aa7f0d7d27f.camel@hadess.net> <000001d47bbf$ae9b99b0$0bd2cd10$@emc.com.tw> <8bc9212689f77cc5f3581a298bfd33ce1bf4e7b2.camel@hadess.net> Message-ID: On Fri, 2018-12-07 at 14:46 +0200, Igor Filatov wrote: > I think Dave means that the scanner would capture the print when the > device is powered on. Not as instructed by a userspace driver, but as > a "hardware feature" of the button/sensor itself. Which might need to be enabled in the hardware. I have a older Lenovo X1 Carbon with that feature, though the fingerprint reader and power button are separate, and the hardware would change colour on boot if it was expecting a fingerprint read. > It would store a single image until asked by libfrint to perform a > scan, at which point it would just submit the image it has. That's probably not something we want to "hide" completely inside the driver. I would much rather this was a separate call if the feature is enabled at all because there are likely cases where admins might want to deactivate this feature. > libfprint doesn't need to know. It only needs to match the print not > aginst the library of a chosen user, but of all users and return a > pair of (ok, user_id). It depends if the enrollment fingerprint is stored in the device, or in user-space in the OS (or if it's possible to enroll multiple users, or multiple fingerprints...) Anyway, there are too many unknowns to discuss this more without some sort of access to the specifications. From hadess at hadess.net Fri Dec 14 14:34:52 2018 From: hadess at hadess.net (Bastien Nocera) Date: Fri, 14 Dec 2018 15:34:52 +0100 Subject: [fprint] Version 0.99.0 released Message-ID: Hey, This is going to be one of the last releases before the 1.0 release. A non-exhaustive list of changes due to happen before 1.0 is available here: https://gitlab.freedesktop.org/libfprint/libfprint/issues?milestone_title=1.0 I expect a number of other changes to also happen in other parts of the OS before 1.0 is released, so that we can get the best documentation, and test infrastructure. Testers will want to give this version a whirl, and if possible compare their experiences with version 0.8.2. We're only interested in new bugs compared to older versions of libfprint. If you have an Elan device, it might be supported now, thanks for Elan providing some protocol information, and Igor Filatov using that information. For driver developers, I would advise you to rebase your tree, and read the driver-specific API documentation at: https://fprint.freedesktop.org/libfprint-dev/pt03.html If you encounter regressions, or find any sort of problem in the documentation, please enter a new issue at: https://gitlab.freedesktop.org/libfprint/libfprint/issues Changes since 0.8.2: * Library: - All the internal API for device driver writers is now covered by the documentation and has been enhanced to make it easier to write drivers - Update internal NBIS fingerprint data processing library to one that's nearly 10 years newer - Re-add accessor for minutia coordinates which was used in the very old fprint_demo program, but also by our new GTK+ test program (see below) - Fix a crash when too many minutiae were detected in a capture * Drivers: - Support more devices in the Elan driver, stability improvements * Tools: - Add a test GTK+ application that will eventually be used for testing drivers without modifying the OS installed version. Note that this application currently requires manually changing permissions of USB devices, this will be fixed when the infrastructure exists to access those devices without additional permissions, as a normal user. Downloads are at: https://gitlab.freedesktop.org/libfprint/libfprint/tags