On Wed, Jun 01, 2016 at 11:11:40AM -0400, John Ferlan wrote: > Or just the raw text in a file. Too bad we couldn't link to the secret > driver file directly... BTW the real for never directly pointing qemu/qemu-img at the files maintained by the secret driver itself is that we don't want to bake in an assumption that they're in a format directly readable by qemu code. Currently the secret driver is lame and just stores the individual files in base64 plain text. At some point I want to integrate the secret driver with DEO[1], so that those files are encrypted. The thing is that with DEO, the virtualization host would never actually have access to the decryption key. The secret driver would read the encrypted file, send it to DEO which decrypts it and sends back the plain text. We would *not* want QEMU to ever talk to DEO directly, so there would be no way for QEMU to directly read the secret driver files and decrypt the data. Regards, Daniel [1] https://blog-ftweedal.rhcloud.com/2015/09/automatic-decryption-of-tls-private-keys-with-deo/ -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list