From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54671)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wouter@grep.be>) id 1a2ckY-0001Wq-0N
	for qemu-devel@nongnu.org; Sat, 28 Nov 2015 05:29:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wouter@grep.be>) id 1a2ckV-0003Jg-B3
	for qemu-devel@nongnu.org; Sat, 28 Nov 2015 05:29:01 -0500
Date: Sat, 28 Nov 2015 11:28:55 +0100
From: Wouter Verhelst <w@uter.be>
Message-ID: <20151128102855.GA20829@grep.be>
References: <1448626853-27450-1-git-send-email-berrange@redhat.com>
	<1448626853-27450-13-git-send-email-berrange@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1448626853-27450-13-git-send-email-berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 12/15] nbd: implement TLS support in the
 protocol negotiation
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: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, qemu-block@nongnu.org

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").

Keeping to these error codes would allow a client to provide more useful
information to a user beyond "haha it fail"; but I suppose there can be
arguments for not doing so, too.

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

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26