Am 06.12.19 um 17:40 schrieb John M. Harris Jr: > >> If the vm is paravirtualized ( i.e. Xen ) you can't even enter a >> plymouth password to unlock a drive. > Well, you can. Why wouldn't you be able to? because I already tried it ;) it's a tty problem with high secure ttys, hvcsomething. Thats the only one, the system accepts input from at start, but with QEMU that tty isn't present. Adding the normal ttys to the trusted list of ttys did not fix the issue. I had a br running years ago, but it got never solved afaik. Maybe i should try again, as the last test was approx. 5 years ago. > Well, VMs are not generally stored on the drive of the host OS, except in one- > offs and on consumer desktops/laptops. If you have an offhost storage, as mass storage at a cloudhoster would be, the transport from the storage to the host needs to be secured too, which i don't think it is. So i don't think we need to even consider VMs to be encryptable, as securing the entire path is very tough and out of our league. >> decrypt the disk." >> >> Add: grub needs an OSK too, or how do you select the matching kernel? > Adding an on-screen keyboard to GRUB would be even more difficult than adding > it to the initramfs environment. GRUB simply cannot support that. It'd have to > be rewritten from the ground up to support that sort of thing. Android did it and M$ helped out with a "on-boot-without-os" OSK in it's surface bios. I guess it's time, to take some stuff back from android to mainstream linux ;) >> Skipping the rest of it, the simple solution to the problem discussed >> would be to ask for encryption more prominent, with a tiny bit of >> background for the user. >> >> Before i forget, there can be multiply passwords for a luks key, so >> there is no need to wipe a disk, just have a good OSK with all installed >> and or system selected languages at hand. > Are you suggesting "translating", for lack of a better term, the passphrase > between all available keyboard layouts? That would decrease the effective > security of your system considerably.. No, i mean, there can be two different passcodes for the same key. Luks offers 10 slots for them. On can be plain ascii as it's now, the other one can be the one the system had been installed with. See it as a "Reserve- or Backuppassword", but in no way it should be a none-interactive password aka controlled by the installer. We don't need backdoors. Best regards, Marius _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
