Fix branding issue with HOTP USB Security Dongles

[alex-nitrokey]

This PR fixes the issue of having the terminology Librem Key everywhere in the code while there are more possible keys. On the same time we want to make it easy for users to know which key to insert. Thus, it is ensured that heads asks for the correct branding after initialization by storing the info in /boot/kexec_hotp_key.

This PR already includes #748 and thus #756 because otherwise it would not function correctly.

Things still needed:

• Include upstream changes (Nitrokey/nitrokey-hotp-verification) once they are ready
• Fix all usage of current librem_hotp_verification PATH accordingly

In best case I can add these tomorrow already.

Please note that I intentionally used other terminology for the variables than discussed in #746 as they felt more suitable for me. Please consider my suggestion and let me know if shall change CONFIG_HOTPKEY to CONFIG_HOTP_USB_SECURITY_DONGLE instead.

[alex-nitrokey]

Ready and tested. Reviews are welcome :)

I am sorry that it took so long and I hope you like this solution.

[tlaurion]

Testing reproducibility from local build and https://app.circleci.com/pipelines/github/tlaurion/heads/255/workflows/8d927eec-1090-4e19-98c2-d2d20682fa4a/jobs/277

[tlaurion]

NitroKey CircleCI:
31e0a25e4dcf2efb2e4f541050db894709c376750bc224b8bc884df74a7e5fcd ./bin/hotp_verification
Local build on debian-10:
ec8c73bbfd7380b7262164d50d8bf25e430b37f71b61543974a7d576d95c1127 ./bin/hotp_verification

`

[tlaurion]

@szszszsz we still have reproducibility issues?

[tlaurion]

Randomly chosen binary:

Nitrokey CI:
9ffac1032dc6805d0a45200d2d9e9543928ecc6555a6c47c7f6a174cb24bfe77 ./lib/libqrencode.so.3

Local:
9ffac1032dc6805d0a45200d2d9e9543928ecc6555a6c47c7f6a174cb24bfe77 ./lib/libqrencode.so.3

[tlaurion]

Building and functionally working, though. :)

[tlaurion]

Note that testing with a Librem Key still asks for user to insert his Nitrokey. Not sure Purism will be happy with that merge.

How is that going be be dealt with finally? Are we expected to duplicate all boards config to have their _Nitrokey _LibremKey derivatives so that it is specified specifically in board configs?

@kylerankin @alex-nitrokey @szszszsz

[tlaurion]

@alex-nitrokey : Im comfortable with CONFIG_HOTPKEY

[alex-nitrokey]

Note that testing with a Librem Key still asks for user to insert his Nitrokey. Not sure Purism will be happy with that merge.

Erm... yes, I guess it is the version with the older firmware were there was a vid:pid error, right? As this PR is checking the vid to decide which device is used, it is difficult to do anything about this issue with the older firmware without breaking the idea of an automatic discovery :(

we still have reproducibility issues?

Will have a look at it with @szszszsz

[alex-nitrokey]

besides hotp_verfication there is a reproducibility problem with

• ./lib/libgcrypt.so.20 and
• ./lib/libassuan.so.0

hotp_initialize buils correctly though.

[szszszsz]

@tlaurion @alex-nitrokey
We should have no repro issues anymore - investigating. Queued job on Gitlab CI.

[alex-nitrokey]

I tested the new circleci hashes with a local build (debian) and they matches for all hotp stuff (though not for the above mentioned).

quite strange...

[szszszsz]

Removed pkg-config and Git version use. Rebuilds queued.

• https://gitlab.com/szszszsz/heads-nitrokey/-/jobs/617694010
• https://app.circleci.com/pipelines/github/Nitrokey/heads/79/workflows/4732f569-535c-4613-938c-9dae61acc6a2/jobs/87

[szszszsz]

@tlaurion @alex-nitrokey
Looks like this change helped. Both builds have deb80848041f503 hashes now for ./bin/hotp_verification. Confirmed as well with local build following Gitlab CI config file.

Regarding #761 (comment) nothing comes to my mind.

[szszszsz]

Hi @alex-nitrokey @tlaurion !

• I believe this PR is ready for merge. If not, what's left here to finish?
• I think the repro build issue mentioned in Fix branding issue with HOTP USB Security Dongles #761 (comment) is not introduced by this PR. Could you confirm or deny @alex-nitrokey ?

[alex-nitrokey]

I believe this PR is ready for merge. If not, what's left here to finish?

I considered it done, yes.

I think the repro build issue mentioned in #761 (comment) is not introduced by this PR. Could you confirm or deny @alex-nitrokey ?

Exactly, it consists independently. Probably after updating gpg2, but I am just guessing here.

[MrChromebox]

not sure why, but this ends up showing my Librem Key as a Nitrokey.
using:
elif lsusb | grep -q "316d:" ; then
works correctly however

[alex-nitrokey]

The negation is used because grep returns 0 if it found something.

Older Librem Keys had the same VID as the Nitrokeys because of a mistake done when building the firmware for it, see #761 (comment)

I could not think of a way to prevent that :(

So I am wondering, what is the return value of lsusb | grep -q "316d:" for you? If it is 0 the patch should work as intended. Does it?

[szszszsz]

In other words first batches of the Librem Key had incorrectly set VID:PID to the same as Nitrokey Pro has, hence the confusion.
Perhaps they have changed the USB names only back then (might not show up in the lsusb, but maybe dmesg) - that would already help to differentiate between models, otherwise I do not see how to make it possible.

[MrChromebox]

So I am wondering, what is the return value of lsusb | grep -q "316d:" for you? If it is 0 the patch should work as intended. Does it?

0, and no the patch does not work correctly with my LK. It identifies as a NK without the change I mentioned above

edit: this LK is one of our new US-built ones with VID/DID 316d:4c4b. Another older one is 20a0:4108 and so identifies as a Nitrokey

[MrChromebox]

pushed #781 to fix