python-validity
python-validity copied to clipboard
uunicorn
Daemon randomly dying on Thinkpad T480
Sometimes I lock my computer and when I come back the fingerprint sensor stops working. I see nothing on dmesg and lsusb still lists the device, but the python3-validity daemon dies, saying the device might have been disconnected (restarting the daemon fixes it):
○ python3-validity.service - python-validity driver dbus service Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; disabled; preset: disabled) Active: inactive (dead)
Jun 03 14:13:26 kubo dbus-service[1227]: ^^^ Jun 03 14:13:26 kubo dbus-service[1227]: File "/usr/lib/python3.12/site-packages/usb/backend/libusb1.py", line 837, in bulk_write Jun 03 14:13:26 kubo dbus-service[1227]: return self.__write(self.lib.libusb_bulk_transfer, Jun 03 14:13:26 kubo dbus-service[1227]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Jun 03 14:13:26 kubo dbus-service[1227]: File "/usr/lib/python3.12/site-packages/usb/backend/libusb1.py", line 938, in __write Jun 03 14:13:26 kubo dbus-service[1227]: _check(retval) Jun 03 14:13:26 kubo dbus-service[1227]: File "/usr/lib/python3.12/site-packages/usb/backend/libusb1.py", line 604, in _check Jun 03 14:13:26 kubo dbus-service[1227]: raise USBError(_strerror(ret), ret, _libusb_errno[ret]) Jun 03 14:13:26 kubo dbus-service[1227]: usb.core.USBError: [Errno 19] No such device (it may have been disconnected) Jun 03 14:13:26 kubo systemd[1]: python3-validity.service: Deactivated successfully.
After some more testing I've confirmed it happens after system goes into suspend. Probably related to issue #173
I'm having a potentially similar issue here. T480 (Arch btw), Gnome DE. Works on install, dies on restart (reboot).
If I type: sudo systemctl restart python3-validity sudo systemctl restart open-fprintd
then it works fine after suspends until I restart the computer again. Looking to see if I can set it to run as a script after I login to the gnome session, but haven't figured that part out yet.
Seems to behave the same in Plasma 6 ( didn't try 5), so doesn't seem to be tied to KDE or GNOME necessarily. Seems to be logging in that breaks it. Luckily, I don't restart the computer often, mostly just suspends or locks.
I'm having a potentially similar issue here. T480 (Arch btw), Gnome DE. Works on install, dies on restart (reboot).
If I type: sudo systemctl restart python3-validity sudo systemctl restart open-fprintd
then it works fine after suspends until I restart the computer again. Looking to see if I can set it to run as a script after I login to the gnome session, but haven't figured that part out yet.
Seems to behave the same in Plasma 6 ( didn't try 5), so doesn't seem to be tied to KDE or GNOME necessarily. Seems to be logging in that breaks it. Luckily, I don't restart the computer often, mostly just suspends or locks.
Not to be a buzzkill, but this software is pretty much abandoned and it depends on an even more abandoned and potentially unsafe fork of fprintd. I would seriously advice against using it until the developer (or someone else) continues development of both the fprintd fork and of this repo.
I am experiencing the same. ThinkPad x380 Yoga with Fedora 40 and GNOME DE. Restarting python3-validity and open-fprintd works. @repomansez is there a project / fork that is actively maintained currently? Otherwise I might just deactivate the fingerprint reader (was happy to get it working a few days ago, but anyways... ^^) or create a systemd unit that restarts both services after resume.
My workaround for now: creating a systemd unit at /etc/systemd/system/validityrestart.service with the following content. Seems to work. Edit: I have to press ESC since after resume I am prompted for my password. ESC brings me back to the user selection. When I then select my user again by ENTER, I am prompted for fingerprint.
[Unit]
After=hibernate.target
After=hybrid-sleep.target
After=suspend.target
After=suspend-then-hibernate.target
[Service]
Type=simple
ExecStart=/bin/systemctl --no-block restart python3-validity.service open-fprintd.service
[Install]
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target
WantedBy=suspend.target
WantedBy=suspend-then-hibernate.target
I am experiencing the same. ThinkPad x380 Yoga with Fedora 40 and GNOME DE. Restarting python3-validity and open-fprintd works. @repomansez is there a project / fork that is actively maintained currently? Otherwise I might just deactivate the fingerprint reader (was happy to get it working a few days ago, but anyways... ^^) or create a systemd unit that restarts both services after resume.
Not that I know of. I've looked. For the time being yeah I'd totally advise you to just forget about the fingerprint sensor.
@warlock94 Thanks for sharing this solution. I have same issue on Debian 12 on T480. It might be obvious, but I had to find out, that creating the the file is not sufficient, it needs this to make it work: systemctl enable validityrestart.service
@repomansez solutions and explanations that can be tried https://github.com/uunicorn/python-validity/issues/128#issuecomment-2437045697
@repomansez solutions and explanations that can be tried #128 (comment)
Again, I'd totally advise to forget about the fingerprint scanner until someone updates this software and fprintd. They are dangerously outdated and are definitely vulnerable, no amount of hacks or quick fixes would make it a good idea to still use this.
@repomansez solutions and explanations that can be tried #128 (comment)
Again, I'd totally advise to forget about the fingerprint scanner until someone updates this software and fprintd. They are dangerously outdated and are definitely vulnerable, no amount of hacks or quick fixes would make it a good idea to still use this.
not entirely true, friend. fprintd is a library. and some errors that occur are more about device compatibility issues, OS, Drivers, or libusb packages, or Bios on devices that use this library.
In fact, I often encounter problems in the libusb library. (Critical) because for security it can be done at the BIOS level. Correct My Answer If It's Wrong.
@repomansez solutions and explanations that can be tried #128 (comment)
Again, I'd totally advise to forget about the fingerprint scanner until someone updates this software and fprintd. They are dangerously outdated and are definitely vulnerable, no amount of hacks or quick fixes would make it a good idea to still use this.
not entirely true, friend. fprintd is a library. and some errors that occur are more about device compatibility issues, OS, Drivers, or libusb packages, or Bios on devices that use this library.
In fact, I often encounter problems in the libusb library. (Critical) because for security it can be done at the BIOS level. Correct My Answer If It's Wrong.
fprintd is a library, yes. open-fprintd is a fork of that library on which this software depends on, and it hasn't been updated for over 4 years now, while fprintd has seen constant developing, and that's why this software is a security nightmare waiting to happen, and I wouldn't recommend using it.
I think I owe an explanation why this project is being neglected for such a long time. While it was fun hacking these sensors, I don't personally use python-validity. Mainly because I don't have a lot of trust in this hardware.
I certainly don't recommend using any fingerprint scanners as a security measure at all. You leave your latent fingerprints all over your laptop and then try to secure it with the same fingerprints. I mean, it could work against your kids or your friends, but it does not add a lot of security on top of a plain autologin.
Speaking of security nightmare, the firmware inside the Synaptics (Validity) devices supported by python-validity have a peculiar "feature" which allows you to create a USB device which can spoof the authentication on any computer (granted you know a private key hardcoded inside the firmware). I'm saying "feature" because trusting a hardcoded key instead of implementing a proper two-way trust between a host and a device was a deliberate decision to compromise security in favor of convenience. And sure enough, there was a vulnerability which exposed this private key, see CVE-2019-18618. What makes it worse is that there is no secure way to recycle this key on existing devices, despite the fact that the actual bug which exposed the key is fixed in the recent versions of the firmware.
So, if you value convenience over security, then python-validity is probably ok, despite all the security drawbacks, however if it's the other way around - you should probably not be using this hardware at all.
ahhh, I see.
so the problem is not with fprintd but with hardware devices that continue to develop. So there are many vulnerabilities in communication concepts that are easy to inject. I finally understand what you mean, friend. That means it depends on the individual who wants to use it, right?