Replace hidapi dependency with libusb1 about python-trezor

[mcudev]

@prusnak I was researching possible application level USB libraries to use to interface with TREZOR v1 devices, and had some questions that coincide with what this issue is advocating.

Since the device registers its interfaces as USB HID with the host system, I'm leaning towards using a hidapi based library by default.

I also found these links that seem to indicate that a hidapi based library may be more compatible with OS X hosts (I don't have one to test):
https://github.com/libusb/libusb/wiki/FAQ#does-libusb-support-usb-hid-devices
https://github.com/gary-rowe/hid4java#why-not-just-use-usb4java-

I'm wondering if you have any experience or guidance with regards to library compatibility, or suggestions to avoid pitfalls? Does the fact that "we don't really need HID features" cancel out the compatibility problems?

Also, it looks like now you're in control of pypi for hidapi, so is this issue still as relevant as it was when you opened it?

I'm debating whether to use Python or Java and have narrowed it down to these options that I'm considering:

For Python:
libusb 1.0 based -> https://pypi.python.org/pypi/libusb1/1.6.4
hidapi based -> https://pypi.python.org/pypi/hidapi/0.7.99.post21

For Java:
libusb 1.0 based -> https://github.com/usb4java/usb4java
hidapi based -> https://github.com/gary-rowe/hid4java

[prusnak]

We'll be switching to WebUSB soon (both for T1 and T2). Further research shows it makes sense to support both (libhidapi for legacy HID and libusb for WebUSB).

Funnily enough, the current implementation for Android (trezor-android) works for both HID and WebUSB.

[mcudev]

Hmm, WebUSB is not very good right now compatibility wise for our purposes.
For example, I'm testing it on Ubuntu 16.04.3 LTS with Chrome 63 and am hitting this issue that the Chrome team has marked as "won't fix": https://bugs.chromium.org/p/chromium/issues/detail?id=679314

To reproduce, plug in T1 device and go to WebUSB test page.
You'll get "DOMException: Unable to claim interface."

Then I run a usb1 python script that contains the following:

    if handle.kernelDriverActive(TREZOR_INTERFACE):
      handle.detachKernelDriver(TREZOR_INTERFACE)

Then I go back to the WebUSB test page and it works.

EDIT: Oh, I just noticed that issue was opened by @karel-3d. Small world :)

[karelbilek]

It should be enough to install the udev rules that we offer with extension - deb package https://wallet.trezor.io/data/udev/trezor-udev_1_all.deb or manually http://doc.satoshilabs.com/trezor-user/settingupchromeonlinux.html

[mcudev]

@karel-3d thanks for the suggestion. i tried it and was able to still reproduce the same issue. it really is the kernel driver issue that you reported. when my python script detaches and does not re-attach the kernel driver, it has the side effect of letting chrome claim the interface afterwards (assuming that i don't unplug my device in-between running the python script and going back over to chrome).

for reference, when the udev rules are incorrect, chrome gives me "DOMException: Access denied." which is different.

fwiw, i was using very liberal udev rules to begin with:

SUBSYSTEM=="usb", ATTR{idVendor}=="534c", ATTR{idProduct}=="0001", MODE="0666"
KERNEL=="hidraw*", ATTRS{idVendor}=="534c", ATTRS{idProduct}=="0001", MODE="0666"

[prusnak]

@mcudev the WIP branch in this PR: trezor/trezor-mcu#260 is supposed to be used with WebUSB. Currently we ship devices with HID for communication and HID for U2F, after the change we will ship devices with WebUSB for communication and HID for U2F.

[karelbilek]

@mcudev oh, you are trying webusb with the current firmware with HID interface? OK, this will not work without detaching the driver.

We are making a new firmware that will not have HID on the first interface (see the linked branch) and that should not require the python script.

[mcudev]

neat. thanks, i'll check that out. that should beat running a script from a udev rule :)

[karelbilek]

@mcudev the problem is that we could not make this backwards compatible. We originally wanted to make the third interface WebUSB and keep the HID interfaces as-are, but there is an issue on windows libusb implementation, that is used in Chrome, where HID and WinUSB (which is needed for WebUSB to work without drivers) are on the same device. WinUSB needs to come before HID.

The resolution is either to wait for Chrome to fix their stuff (they are completely rewriting the usb backend away from libusb), or to put WinUSB/WebUSB first. Which will break things like python-trezor.anyway (if we kept HID but put it on interface 3). And if we put WebUSB first and swith HID to 3, we need to rewrite python-trezor anyway.

We decided to ax HID interface and keep only the webusb one, because the implementation will be cleaner.

[mcudev]

Yeah, that's a tough spot to be in. No great option so far. I was thinking of fingerprinting the host during enumeration to determine which order of interface descriptors to send, but that may be too brittle.

Hopefully the package maintainers for python-trezor will update in a timely manner when this is ready (e.g.- the debian package [and downstream systems] has only been updated once in the last year+).

[karelbilek]

Fingerprinting OS would break python-trezor on Windows anyway. I thought about somehow faking the vendor class for Libusb (or finding some way for libusb to make it just skip the interface and think it's not hid), but seems like it's not possible. (I have looked into the libusb windows code, but I have 0 experience with building and debugging stuff on Windows, so I stopped there :( ). See https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c

…

On Dec 15, 2017 17:58, "mcudev" ***@***.***> wrote: Yeah, that's a tough spot to be in. No great option so far. I was thinking of fingerprinting the host during enumeration to determine which order of interface descriptors to send, but that may be too brittle. Hopefully the package maintainers for python-trezor will update in a timely manner when this is ready (e.g.- the debian package [and downstream systems] has only been updated once in the last year+). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGZ8fL5AzWbpp6gNRD34F62ivJCvkM1ks5tAqUygaJpZM4MUDlI> .

[matejcik]

in the meantime I'm going to try to switch to hidapi-cffi so that we can get rid of Cython

[matejcik]

using hidapi-cffi is not viable because of Windows - we'd need to supply a separate dll. That's the advantage of Cython-based hidapi.

hidapi feature is now marked as extra in python-trezor, so the dependencies don't install by default. That is in anticipation of T1 switch to WebUSB. I'd consider the bug closed through this -- a full switch is not going to happen, AFAICT, we will need to support hidapi as a legacy option in any case.