On Tue, Nov 03, 2015 at 03:01:16PM +0800, Fam Zheng wrote: > This would be a safer channel when we want to provide block options that > contain sensitive information, such as fields for authentication.
If passing of security sensitive data is the motivation for this, then I don't think we want it really. This approach merely avoids the config being visible in the process listing, which is really just one problem. When people file bugs they are going to need to provide the block device config, and that still going to contain sensitive info and thus leak. Similarly apps generating block config like libvirt are still going to be logging the block config they generate, which is again going to leak secrets. Finally, we need the ability to pass security sensitive data to QEMU in many other areas besides block devices so need a more general mechanism I've proposed a way to provide secrets to QEMU in a way that is usable across all QEMU backends, that I think is a much better approach because it totally decouples the sensitive data from the rest of the config data, rather than having it inline https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg04365.html Regards, Daniel -- |: 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 :|
