From: "Daniel P. Berrange" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
qemu-block@nongnu.org, Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
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 [thread overview]
Message-ID: <20151019162425.GF17892@redhat.com> (raw)
In-Reply-To: <56251685.9050806@redhat.com>
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 :|
next prev parent reply other threads:[~2015-10-19 16:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 15:09 [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 01/17] crypto: add QCryptoSecret object class for password/key handling Daniel P. Berrange
2015-10-19 15:18 ` Paolo Bonzini
2015-10-19 15:24 ` Daniel P. Berrange
2015-10-19 15:40 ` Paolo Bonzini
2015-10-19 15:46 ` Daniel P. Berrange
2015-10-19 16:12 ` Paolo Bonzini
2015-10-19 16:24 ` Daniel P. Berrange [this message]
2015-10-19 16:28 ` Paolo Bonzini
2015-10-19 16:30 ` Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 02/17] crypto: add support for loading encrypted x509 keys Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 03/17] rbd: add support for getting password from QCryptoSecret object Daniel P. Berrange
2015-10-19 22:57 ` Josh Durgin
2015-10-20 8:35 ` Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 04/17] curl: add support for HTTP authentication parameters Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 05/17] iscsi: add support for getting CHAP password via QCryptoSecret API Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 06/17] qcow: add a 'keyid' parameter to qcow options Daniel P. Berrange
2015-10-28 13:56 ` Eric Blake
2015-10-19 15:09 ` [Qemu-devel] [PATCH 07/17] qcow2: add a 'keyid' parameter to qcow2 options Daniel P. Berrange
2015-10-19 23:29 ` Eric Blake
2015-10-28 13:58 ` Eric Blake
2015-10-19 15:09 ` [Qemu-devel] [PATCH 08/17] qom: add user_creatable_add & user_creatable_del methods Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 09/17] qemu-img: add support for --object command line arg Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 10/17] qemu-nbd: " Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 11/17] qemu-io: " Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 12/17] qemu-io: allow specifying image as a set of options args Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 13/17] qemu-nbd: " Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 14/17] qemu-img: " Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 15/17] block: rip out all traces of password prompting Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 16/17] block: remove all encryption handling APIs Daniel P. Berrange
2015-10-19 15:09 ` [Qemu-devel] [PATCH 17/17] block: remove support for writing to qcow/qcow2 encrypted images Daniel P. Berrange
2015-10-19 16:05 ` [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU Alex Bennée
2015-10-19 16:14 ` Daniel P. Berrange
2015-10-19 17:13 ` Dr. David Alan Gilbert
2015-10-19 17:46 ` Daniel P. Berrange
2015-10-23 15:31 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151019162425.GF17892@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).