qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/17] crypto: add QCryptoSecret object class fo


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 01/17] crypto: add QCryptoSecret object class for password/key handling
Date: Mon, 19 Oct 2015 17:24:25 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Oct 19, 2015 at 06:12:53PM +0200, Paolo Bonzini wrote:
> 
> 
> On 19/10/2015 17:46, Daniel P. Berrange wrote:
> >> > The difference is that guest-file-read/write have the payload in JSON;
> >> > for file-based secrets the payload is not JSON.
> > For non-file based secrets though, the payload *is* in the JSON,
> > and per the cover letter, I actually anticipate passing all
> > secrets inline in the JSON and only using the file backend for
> > loading the initial master key. This avoids the need to do
> > file handle passing and/or create lots of temporary files, when
> > hotplugging resources.
> > 
> > > So I think that "binary" (which is the default anyway) would fit all the
> > > usecases (direct over JSON, file-based, direct over command line).
> > > Direct over JSON would be limited to valid UTF-8, but that's just a
> > > limitation of the transport.
> > 
> > I don't think that's actually an acceptable limitation - I want the
> > inline data passing to be fully usable for non-UTF-8 data too.
> 
> Of course, there's base64 for that.  On the other hand, I think there's
> no reason for unencoded file-based data passing to be usable for UTF-8
> data only.

Ok, so there's really two separate formats at play here.

The input format, eg the encoding of the data=XXXX value, or the contents
of the file, and the output format, which is that required by the consumer
inside QEMU. We convert between the two. eg you can provide data in base64
even if QEMU ultimately needs to use it in plain utf-8 format, or vica-verca.

IIUC, you're suggesting that for the input format, the data=XXX value
should allow a choice of utf8 or base64, while the external file could
just take raw or base64 data. That's easy enough to wire up - just add
a 3rd option to the format enum and make raw be the default for files.

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]