Nitrokey / nitrokey-hotp-verification

A command line C app to validate HOTP codes on Heads
GNU General Public License v3.0
11 stars 10 forks source link

Invalid connected device name #12

Closed szszszsz closed 1 year ago

szszszsz commented 4 years ago

And libusb is used correctly, resulting in HOTP validation working: hotp-works (@szszszsz @kylerankin @jans23: Note that the key should be detected as a Librem Key on this test, not a Nitrokey)

Source: https://github.com/osresearch/heads/pull/657


Hi @tlaurion,

Could you tell which commit of the tool was used in this case? Is it current master / 1ae3c5be091a3bd8d2bf2b2469d9694be2be06e2 or v1.1? From below excerpt I understand latest commit is used, but I want to confirm:

https://github.com/osresearch/heads/blob/ac71f295a08f8139d2d4a5e6496d6e14f7b7690e/modules/libremkey-hotp-verification#L5-L7

szszszsz commented 4 years ago

@tlaurion Currently the name should be taken from the PID:VID pair. Could you check, if your Librem Key uses the correct one (e.g. with lsusb)?

https://github.com/Nitrokey/nitrokey-hotp-verification/blob/1ae3c5be091a3bd8d2bf2b2469d9694be2be06e2/device.c#L34-L45

https://github.com/Nitrokey/nitrokey-hotp-verification/blob/1ae3c5be091a3bd8d2bf2b2469d9694be2be06e2/device.c#L123-L133

tlaurion commented 4 years ago

And libusb is used correctly, resulting in HOTP validation working: hotp-works (@szszszsz @kylerankin @jans23: Note that the key should be detected as a Librem Key on this test, not a Nitrokey)

Source: osresearch/heads#657

Hi @tlaurion,

Could you tell which commit of the tool was used in this case? Is it current master / 1ae3c5be091a3bd8d2bf2b2469d9694be2be06e2 or v1.1? From below excerpt I understand latest commit is used, but I want to confirm:

https://github.com/osresearch/heads/blob/ac71f295a08f8139d2d4a5e6496d6e14f7b7690e/modules/libremkey-hotp-verification#L5-L7

@szszszsz : rebuilding with rm -rf build/librem*

tlaurion commented 4 years ago

libremkey_seen_as_nitrokey lsusb

tlaurion commented 4 years ago

@szszszsz : latest (see created reproducibility issue here): "The trick applied upstream to fix commit IDs cannot be applied because it relies on hidapi. That needs to be fixed since, once again, upstreamed version changed last week and CI caches builds unless cache are flushed manually and restarted, which then builds from scratch."

Consequently, the only way to make sure we are building from upstreamed version is to rm -rf build/* content, which is undesired. The build logs on CI won't show what was downloaded:

git clone --recursive https://github.com/Nitrokey/nitrokey-hotp-verification "/home/user/heads/build/libremkey-hotp-verification"
Cloning into '/home/user/heads/build/libremkey-hotp-verification'...
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 124 (delta 22), reused 35 (delta 19), pack-reused 78
Receiving objects: 100% (124/124), 169.55 KiB | 460.00 KiB/s, done.
Resolving deltas: 100% (60/60), done.
Submodule 'hidapi' (https://github.com/Nitrokey/hidapi.git) registered for path 'hidapi'
Cloning into '/home/user/heads/build/libremkey-hotp-verification/hidapi'...
remote: Enumerating objects: 3, done.        
remote: Counting objects: 100% (3/3), done.        
remote: Compressing objects: 100% (3/3), done.        
remote: Total 1815 (delta 0), reused 0 (delta 0), pack-reused 1812        
Receiving objects: 100% (1815/1815), 2.73 MiB | 482.00 KiB/s, done.
Resolving deltas: 100% (1056/1056), done.
Submodule path 'hidapi': checked out 'e5ae0d30a523c565595bdfba3d5f2e9e1faf0bd0'
cd /home/user/heads/build/libremkey-hotp-verification && git submodule update --init --checkout
if [ -r patches/libremkey-hotp-verification.patch ]; then ( cd /home/user/heads/build/libremkey-hotp-verification ; patch -p1 ) < patches/libremkey-hotp-verification.patch || exit 1 ; fi
patching file Toolchain-heads.cmake
patching file device.c
Hunk #1 succeeded at 46 with fuzz 2 (offset 12 lines).
patching file libremkey_hotp_initialize
if [ -d patches/libremkey-hotp-verification ] && [ -r patches/libremkey-hotp-verification ] ; then for patch in patches/libremkey-hotp-verification/*.patch ; do echo "Applying patch file : $patch " ; ( cd /home/user/heads/build/libremkey-hotp-verification ; patch -p1 ) < $patch || exit 1 ; done ; fi
2020-01-26 13:40:22-05:00 CONFIG libremkey-hotp-verification
2020-01-26 13:40:24-05:00 MAKE libremkey-hotp-verification
2020-01-26 13:40:25-05:00 DONE libremkey-hotp-verification
2020-01-26 13:40:25-05:00 INSTALL-BIN build/libremkey-hotp-verification/libremkey_hotp_verification
2020-01-26 13:40:25-05:00 INSTALL-BIN build/libremkey-hotp-verification/libremkey_hotp_initialize
szszszsz commented 4 years ago

I see where the problem lies. The 20a0:4108 is a Nitrokey Pro USB VID:PID pair, hence it shows the Nitrokey Pro is connected. The proper 316d:4c4b USB pair of Librem Key is probably used in a later batch. cc: @kylerankin @jans23

I will remove the "Connected to %s. \n" line for now, as it seems to not suit UI anyway.

szszszsz commented 1 year ago

This seems to be corrected. Closing as done.