From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtWS4-00088l-CL for qemu-devel@nongnu.org; Tue, 03 Nov 2015 02:56:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtWS3-0001Bj-FE for qemu-devel@nongnu.org; Tue, 03 Nov 2015 02:56:20 -0500 Date: Tue, 3 Nov 2015 15:56:11 +0800 From: Fam Zheng Message-ID: <20151103075611.GA13105@ad.usersys.redhat.com> References: <1446534078-11172-1-git-send-email-famz@redhat.com> <20151103073529.GB10551@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151103073529.GB10551@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/2] block: Introduce "json-file:" protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz On Tue, 11/03 07:35, Daniel P. Berrange wrote: > 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 > Apparently I've overlooked your post, thanks for pointing out. I think your solution covers everything this series has to do. Fam