Push distros to configure canokey under qemu packaging

[tlaurion]

Looked around quickly.
Found that Nix has canokey configured under their qemu 8.0 packages.
debian-12 experimental repos have 8.0 but didn't configure for canokey to be included under their current qemu packages. This is major in my opinion and should be addressed, since debian build recipes are mostly reused everywhere for packaging bases.

Goal here would be for people to be able to use canokey in their qemu tests when smartcards are needed instead of using real external devices, but it seems that canokey is not included currently in distros. Was wondering if the word was told.

The word has been passed around for canokey inclusion for qemu packaging?

Asking because Heads has a qemu-coreboot-tpm(1/2) targets, and I would like to dodge having build recipes for devs to also have to build canokey+qemu on their build hosts to run tests. Just like swtpm is getting traction (packaged under debian-12, nix) I think qemu packagers should have the word to change their build recipes to have canokey readily available. Just starting to attack linuxboot/heads#1207 and this makes it a bit more complicated.

It's sad to see
qemu-system-x86_64: -device canokey: 'canokey' is not a valid device model name

[ZenithalHourlyRate]

Found that Nix has canokey configured under their qemu 8.0 packages.

I know this. I heard that they used it for testing LUKS setup in CI.

Was wondering if the word has been passed around for canokey inclusion for qemu packaging?

Well the policy regarding virtual key is that it is only for testing and delivering it to every end user is strongly not recommended as it is not secure at all and the end user may not be aware of such risk.

[tlaurion]

@oxalica, is there any reason why there is not a qemu nix derivate that does that would build qemu with canokey without needing to understand nix completely?

Ref: NixOS/nixpkgs#194254
Why is there not a qemu-canokey-lib (instead of misleading canokey-qemu) and then a qemu-canokey that is actually qemu-canokey producing qemu derivative that would be usable directly from developer shell? That would be a step forward into making it used, known, tested and maintained?

[oxalica]

@oxalica, is there any reason why there is not a qemu nix derivate that does that would build qemu with canokey without needing to understand nix completely?

Ref: NixOS/nixpkgs#194254

The name canokey-qemu is a direct copy of this repo. And that derivation is just a package for this repo, ie. a library with one libcanokey-qemu.so.0, headers and .pcs.

... qemu derivative that would be usable directly from developr shell

If you want a QEMU with canokey support, use qemu.override { canokeySupport = true; } which is the QEMU configured to link in libcanokey-qemu.so to gain that support. For non-flake, that's nix-shell --expr '(import <nixpkgs> {}).qemu.override { canokeySupport = true; }'. It may require a rebuild of QEMU through.

making it used, known, tested and maintained?

It is used in luks tests as mentioned above, so it should be tested regularly as a part of the hydra CI.

The only bit missing is that's not enabled by default. My reason is that it's kinda niche and most QEMU users does not really need it.

[tlaurion]

@oxalica thanks for your quick reply!

The only bit missing is that's not enabled by default. My reason is that it's kinda niche and most QEMU users does not really need it.

I just discussed, and the fault was totally mine: I was declaring both qemu and then the override in my flake.nix.
I'm watching the build happen with nix -L and the configure step and qemu-canokey library was found, so I'm hopeful the final derivative with have canokey support built in.

Why is there not a qemu-canokey-lib (instead of misleading qemu-canopy) and then a qemu-canokey that is actually qemu-canokey producing qemu derivative that would be usable directly from developr shell?

My point still stands here though.
By having qemu-canokey -> qemu-canokey-lib and having a qemu-canokey which is a direct derivative of qemu with canokey support configured in, people wanting to use qemu-canokey (enabled) would eventually only have to specify qemu-canokey instead of qemu, and eventually not have to build it themselves. Prebuilt qemu-canokey enabled binaries will most probaly end in cache since as you said, even Nix infra people use it so they would probably cache that derivative as well.

Sorry for being a newbie of Nix, learning my way as I go to fulfill reproducible builds need here for my own project's buildsystem and testing or reproducible produced roms.

I still believe it would be beneficial to have that package at the end cached and downloadable without building it, where explicitly asking for qemu-canokey instead of qemu should dodge the concerns raised in that issue to "not make this experiemental feature in qemu built-in by default" .

[tlaurion]

@oxalica @ZenithalHourlyRate relevant linuxboot/heads#1661 (comment)

[tlaurion]

@oxalica @ZenithalHourlyRate any interest into developing reverse HOTP inside of canokey?
linuxboot/heads#1671 (comment)