Presumably this would primarily have to happen in GNOME. I don't see any open tickets for it against gnome-shell or gdm.

Keep in mind that Howdy should be treated with special care due to potential security issues -> https://github.com/boltgolt/howdy#a-note-on-security

Keep in mind that Howdy should be treated with special care due to potential security issues -> https://github.com/boltgolt/howdy#a-note-on-security

This is a general warning related to all biometric logins. Microsoft explicitly states that Windows Hello is a convenience login. Login based on camera will always have the potential of being tricked. Howdy did an exact implementation of the Windows Hello standard and of course they put the Windows Hello warning there in their repository.

Just a note, I've started to look into this a bit.

To do proper integration we'll need changes to authselect, gdm, gnome-shell, gnome-control-center, and howdy itself.

I'm putting together the changes now so we can try it out. I'll try to post a copr in a few days. I'm not completely sold on whether or not we should do it, but I think it's worth exploring.

Howdy currently does everything relative to where it's installed (so config files and camera data in /usr/lib64). This isn't a great idea architecturally, and is incompatible with SELinux and Silverblue/ostree, so I have some patches to fix that. I haven't discussed these changes with upstream yet. I plan to engage once I get all the pieces together.

Another issue is the config file requires choosing a specific video device and it's not always clear which one is the "right" one. In fact, the best one to use, it seems, if available is the IR camera, with fall back to the all purpose webcam.

I had started to write some code to auto detect the best camera to use and not require the configuration, but it occurred to me the detection logic should really happen on the control-center side when enrollment takes place. So keeping the config file entry is probably okay. I'm working on prototyping the control-center integration now, should be done soon I think.

I also ran into issues with dlib on the latest rawhide last week. I did some quick fixes to get it working with cpython 3.11 but those were pretty minor changes due to the api shifting.

Anyway, will post another update soonish.

Another issue is the config file requires choosing a specific video device and it's not always clear which one is the "right" one. In fact, the best one to use, it seems, if available is the IR camera, with fall back to the all purpose webcam.

We started working on something in these lines for Cheese/Camera apps. Basically a systemd hwdb where we will be tagging cameras and their properties. https://github.com/systemd/systemd/commit/e78e11d8c59727aee2e6f03ce413ee73193e1937

More cameras wanted for the database! :)

oh that's cool!

hmm, though, in my case, both the IR and all purpose camera have the same name, vendor id, model id, and serial number.

It seems the best way to know on my dell xps 13 is based on what capture formats the /dev/video node exposes

One of my laptops exposes a separate IR camera device, so it seems to vary among cameras.

sure and even in my case maybe we could fix uvcvideo or whatever to give make the IR camera more easily identifiable for hwdb purposes. Certainly, "query udev" is the nicest answer from the app side if we can make it work generally.

Upstream design ticket: https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/174

This isn't going to happen for F37. Changing milestone to F38.

Just a note, I've started to look into this a bit.

To do proper integration we'll need changes to authselect, gdm, gnome-shell, gnome-control-center, and howdy itself.

I'm putting together the changes now so we can try it out. I'll try to post a copr in a few days.

@rstrode these are famous last words. ;) Any update?

I checked in with @rstrode about this yesterday. He'd still like to work on this, and plans to get back to it, but it's currently on the backburner.

I don't think we can continue to track this here. It is not being actively-developed, and Fedora Workstation WG is not a good place to track work that we wish people would work on but are not working on. We're better at tracking issues that are being actively developed.

Suggestion: close this issue?