From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40988)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1a44us-0003Rd-7o
	for qemu-devel@nongnu.org; Wed, 02 Dec 2015 05:45:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1a44uq-00006j-Tc
	for qemu-devel@nongnu.org; Wed, 02 Dec 2015 05:45:42 -0500
Date: Wed, 2 Dec 2015 10:45:30 +0000
From: "Daniel P. Berrange" <berrange@redhat.com>
Message-ID: <20151202104530.GF15721@redhat.com>
References: <1448626853-27450-1-git-send-email-berrange@redhat.com>
	<1448626853-27450-13-git-send-email-berrange@redhat.com>
	<20151128102855.GA20829@grep.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20151128102855.GA20829@grep.be>
Subject: Re: [Qemu-devel] [PATCH 12/15] nbd: implement TLS support in the
 protocol negotiation
Reply-To: "Daniel P. Berrange" <berrange@redhat.com>
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Wouter Verhelst <w@uter.be>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, qemu-block@nongnu.org

On Sat, Nov 28, 2015 at 11:28:55AM +0100, Wouter Verhelst wrote:
> Minor nitpick:
> 
> On Fri, Nov 27, 2015 at 12:20:50PM +0000, Daniel P. Berrange wrote:
> [...]
> > @@ -563,6 +659,14 @@ static int nbd_receive_options(NBDClient *client)
> >              case NBD_OPT_EXPORT_NAME:
> >                  return nbd_handle_export_name(client, length);
> >  
> > +            case NBD_OPT_STARTTLS:
> > +                if (client->tlscreds) {
> > +                    TRACE("TLS already enabled");
> > +                } else {
> > +                    TRACE("TLS not configured");
> > +                }
> > +                nbd_send_rep(client->ioc, NBD_REP_ERR_UNSUP, clientflags);
> 
> NBD_REP_ERR_UNSUP is supposed to be reserved as the default reply for
> replies unknown to a server implementation (i.e., it's "this request is
> not supported by this server"). Trying to negotiate TLS in a TLS channel
> would be NBD_REP_ERR_INVALID ("invalid request"). Trying to negotiate
> TLS when no TLS configuration is available server-side would be
> NBD_REP_ERR_POLICY ("request not allowed by server-side policy").

Yep that makes sense.

> Beyond this and the default export that I talked about earlier, no
> comments.

Ok, thanks for taking the time to look at this.

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