canokey-qemu: mark broken

[emilazy]

Uses a four‐year‐old patched vendored version of Mbed TLS for cryptography that doesn’t build with CMake 4. Doesn’t build with current versions of canokey-core, either. No upstream development since 2023.

This was only used in‐tree by the systemd-initrd-luks-fido2 NixOS test, which is not a channel blocker and that I couldn’t find a historical failure for that wasn’t related to issues with the test driver.

cc @tlaurion as Alyssa mentioned you were invested in the support here. Unfortunately it seems like CanoKey upstream has somewhat abandoned the QEMU library. Even if it was bumped to work with the current canokey-core, canokey-crypto is still on the same version of Mbed TLS from 2021. I get the impression that upstream are not very invested in the software QEMU support, and are focused on hardware keys that use separate accelerated cryptography implementations. Maybe they could use help getting things updated?

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[oxalica]

I'm fine with this decision. But it would be good to have an alternative systemd FIDO2 test. I'm pretty sure there are many ones using it (including me) and it would be terrible to break accidentally, eg. during systemd update.

[emilazy]

I agree it would be good. Unfortunately, CanoKey is the only virtual CTAP library QEMU supports; it supports a software‐emulated U2F device, but I don’t think that would work with the FIDO2 hmac-secret stuff (and the library seems even more unmaintained).

We could perhaps have a manually‐run test that passes through a host FIDO2 device – that wouldn’t work on Hydra, but it’s not a channel blocker to begin with, so manually running these tests is the only way they prevent issues from reaching the channels anyway. It would also be a more end‐to‐end test, which is nice, albeit less convenient to run.

Ideally, we could get canokey-qemu on an up‐to‐date canokey-core and canokey-core on an up‐to‐date Mbed TLS, since relying on a library seemingly abandoned by its upstream to keep this tested doesn’t seem ideal, especially if systemd starts exposing newer FIDO2 functionality in future. My sense is that the test is relatively unlikely to catch issues specific to our NixOS integration, which is quite minimal, though. It would be useful if systemd cuts a release with totally broken FIDO2 support. I don’t think that’s happened and I’d hope it’d be caught in the release candidate phase, but I admittedly don’t know how thorough their QA is.