Push distros to configure canokey under qemu packaging #6
Comments
I know this. I heard that they used it for testing LUKS setup in CI.
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. |
|
@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
If you want a QEMU with canokey support, use
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. |
|
@oxalica thanks for your quick reply!
I just discussed, and the fault was totally mine: I was declaring both qemu and then the override in my flake.nix.
My point still stands here though. 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" . |
|
@oxalica @ZenithalHourlyRate any interest into developing reverse HOTP inside of canokey? |
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
Given that we were overriding qemu_test to enable this anyway, enabling this by default saves Hydra a QEMU build. There's also clear demand from users[1] for this feature, so our alternatives are: - Offer a qemu-canokey attribute. I don't want to do this, because I don't think there's any reason to make Hydra build an extra QEMU. - Enable it only for qemu_test. I don't want to do this, because it will lead to users using qemu_test without understanding its subtleties. - Force users to build from source. I don't think there's any reason to do this when it's unlikely to hurt anybody having it enabled by default. There's no reason to single out canokey to be disabled by default in spite of users' needs given that we enable so many other optional QEMU features. [1]: canokeys/canokey-qemu#6
|
@oxalica this is now part of nixos-unstable as per https://nixpk.gs/pr-tracker.html?pr=311914 and linuxboot/heads#1687 I guess this issue can be closed considering Nix is now shipping it by default and setting example to follow if needed by others. Please share thoughts under #7 |
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 nameThe text was updated successfully, but these errors were encountered: