Allow using hidapi 0.15.0?

[kastl-ars]

Dear maintainers,

pynitrokey is pinning the hidapi version to 0.14.0.post2:

pynitrokey/pyproject.toml

Line 29 in 53a838d

"hidapi ==0.14.0.post2 ; sys_platform == 'linux'",

There is a new version of hidapi:
https://github.com/trezor/cython-hidapi/releases/tag/0.15.0
https://pypi.org/project/hidapi/

Did anyone test yet if this is working?

Kind Regards,
Johannes

[robin-nitrokey]

Hi Johannes,

this is a tricky topic. Generally, pynitrokey should work with hidapi v0.15.0. But there are two backends for hidapi, hidraw and libusb. You can select a backend when building the wheel. v0.14.0post2 is the only version where the wheel on PyPI is built with hidraw.

Using the libusb backend instead of hidraw has two potential problems:

• The paths for the USB devices change, e. g. 1-1:1.1 instead of /dev/hidraw1. This should probably be fine, but as we mainly use hidraw so far, there could be code that assumes a hidraw path.
• Our udev rules for a long time only included the rules needed for hidraw, not for libusb. We have changed that early last year in v1.1.0 of the udev rules but I suspect that many users are still using the old rules, especially if they use the rules packaged by Debian, Ubuntu, etc. In these cases, changing the backend would cause a permission error.

This is why we are currently pinning the hidraw version. What’s the reason for your question? Is the pin causing problems for you? If you package pynitrokey or want to install it on your own system, you can simply ignore the restriction if you are aware of the two potential problems I described.

[kastl-ars]

Sorry for the late reply. And thanks for the details. I will check how the openSUSE hidapi package is being built and will remove the pin, if it is safe.

[robin-nitrokey]

Ah, I wasn’t aware that you are packaging pynitrokey for openSUSE. Thank you!

Which source do you use for the udev rules? I see that they are included in the libnitrokey package. If this is the only version that is shipped, using the libusb backend will probably cause issues.

[jjakob]

@kastl-ars have you tested it with hidapi 0.15.0 and the latest nitrokey-udev-rules v1.1.0? Gentoo has already removed hidapi 0.14.0 from its repositories so they are no longer installable, and has masked all packages that depend on it, including pynitrokey (dev-python/nitrokey and app-crypt/nitrokey-app2). I maintain my own versions in my overlay so I might try to bump the hidapi dep and see if it works.

[jjakob]

I updated my ebuild to use hidapi 0.15.0 and nitrokey-udev-rules 1.1.0, nitropy nk3 operations and firmware upgrades work, but I noticed that pcscd udev rules override the nitrokey rules for the paths in /dev/bus/usb (the group is pcscd, but the ACL still has my user as rw so it still works regardless), those in /dev/hidraw* and /dev/usb/hiddev* are created with an ACL for my user rw, so the nitrokey rules are probably still working for these.