libremkey-hotp-verification: toolchain adjustments

[MrChromebox]

Pass through new toolchain path via $(CROSS) so we can set the
c/c++ compiler paths correctly for CMake. Adjust patch to use
new paths, and fix compiler/linker paths to correct a libusb linking issue.

This fixes compilation of the libremkey-hotp-verification module, which was broken
when toolchain was changed to musl-cross-make in commit 791d064.

CMake isn't my forte, so open to "better" solutions.
Fix derived from: https://stackoverflow.com/questions/36195791/

Signed-off-by: Matt DeVillier matt.devillier@puri.sm

[tlaurion]

@MrChromebox This looks better then my own attempts (CMake)

I would merge, since it is functional in my tests on the x230 adding CONFIG_LIBREMKEY=y in the x230 board config.

The resulting build/log/libremkey-hotp-verification.configure.log looks sane under fedora-30:

INSTALL=/home/user/heads/install CROSS=/home/user/heads/crossgcc/bin/x86_64-linux-musl- cmake -DCMAKE_TOOLCHAIN_FILE=./Toolchain-heads.cmake -DCMAKE_AR=/home/user/heads/crossgcc/bin/x86_64-linux-musl-ar .
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /home/user/heads/crossgcc/bin/x86_64-linux-musl-gcc
-- Check for working C compiler: /home/user/heads/crossgcc/bin/x86_64-linux-musl-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/user/heads/crossgcc/bin/x86_64-linux-musl-gcc
-- Check for working CXX compiler: /home/user/heads/crossgcc/bin/x86_64-linux-musl-gcc -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/heads/build/libremkey-hotp-verification

And libusb is used correctly, resulting in HOTP validation working:

(@szszszsz @kylerankin @jans23: Note that the key should be detected as a Librem Key on this test, not a Nitrokey)

@flammit, should we merge ?

It's been a while that i've tested the main osresearch branch. Unfortunately, injecting public key corresponding to the USB Security dongle in rom can't sign /boot:

[MrChromebox]

@tlaurion I'm seeing the same thing here, so let's hold off. I had only did a quick test with the factory reset, and since that succeeded I thought things were good to go. Apparently not.
(I'm also seeing the incorrect NK vs LK 'branding')

[tlaurion]

Found the culprit:

But not found the cause of why TTY support is now missing.
pinentry-tty is stated to be used under .gpg/gpg-agent.conf, compiled and deployed under modules/pinentry

EDIT: points verified:

• Kernel has TTY_PRINTK
• TTY is enforced by init
  ... Out of ideas for the moment.

[tlaurion]

Well, we have non-working tty, even though tty0 is enabled:

[MrChromebox]

@tlaurion looking at ./build/pinentry-1.1.0/config.log, seems like there's quite a few errors that warrant investigation

[tlaurion]

@tlaurion looking at ./build/pinentry-1.1.0/config.log, seems like there's quite a few errors that warrant investigation

#662

[tlaurion]

@osresearch @MrChromebox : Not reproducible as of right now.

On fedora-30, it produces:

cat build/x230/hashes.txt |grep librem
379725790bc5e7a84c24009fb1d503c6dfc190ca7f632908ee87c08a49fb4f77  ./bin/libremkey_hotp_verification

[tlaurion]

Merging. Reproducibility issue is here