qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 16:46:27 +0100	[thread overview]
Message-ID: <20151019154627.GD17892@redhat.com> (raw)
In-Reply-To: <56250ED8.2000406@redhat.com>

On Mon, Oct 19, 2015 at 05:40:08PM +0200, Paolo Bonzini wrote:
> 
> 
> On 19/10/2015 17:24, Daniel P. Berrange wrote:
> > JSON doesn't accept arbitrary 8-bit binary data, so the alternative
> > 'base64' is effectively providing binary data facility. Having to
> > use base64 for plain passwords is rather tedious though, so allowing
> > utf8 is a much more developer friendly approach for people using QEMU
> > without a mgmt tool like libvirt.
> > 
> > NB, this dual-format utf8-or-base64 approach matches the approach used
> > in QEMU guest agent for the guest-file-read/write commands for the same
> > reason.
> 
> 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.

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	other threads:[~2015-10-19 15:46 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 [this message]
2015-10-19 16:12           ` Paolo Bonzini
2015-10-19 16:24             ` Daniel P. Berrange
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=20151019154627.GD17892@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).