From: Wouter Verhelst <w@uter.be>
To: Eric Blake <eblake@redhat.com>
Cc: Alex Bligh <alex@alex.org.uk>,
"nbd-general@lists.sourceforge.net"
<nbd-general@lists.sourceforge.net>,
"Daniel P. Berrange" <berrange@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS
Date: Sat, 9 Apr 2016 11:55:45 +0200 [thread overview]
Message-ID: <20160409095545.GG19023@grep.be> (raw)
In-Reply-To: <57066F3B.7010500@redhat.com>
On Thu, Apr 07, 2016 at 08:31:23AM -0600, Eric Blake wrote:
> > +The FORCEDTLS mode of operation has an implementation problem in
> > +that the client MAY legally simply send a `NBD_OPT_EXPORT_NAME`
> > +to enter transmission mode without previously sending any options.
> > +Therefore, if a server uses FORCEDTLS, it SHOULD implement the
> > +INFO extension.
>
> I'd go one step further:
>
> If a server uses FORCEDTLS, it MUST implement the
> NBD_FLAG_FIXED_NEWSTYLE flag, and SHOULD implement the INFO extension.
Yes.
> That way, a client can send ANY option to learn if TLS is required (even
> an option that the server does not recognize); where NBD_OPT_INFO and
> NBD_OPT_LIST are probably the two most useful options, but where ANY
> option works. A server with TLS but not FIXED_NEWSTYLE is pointless
Actually, such a server is technically impossible ;-)
> (since TLS was introduced at the same time as fixed newstyle,
Eh. I don't know where you got that idea, but that's absolutely not
true. Fixed newstyle was introduced five years ago, TLS was introduced
last year or so.
> we can reasonably require, rather than just suggest, that both things
> be implemented at once to be a compliant FORCEDTLS server).
We have to make fixed newstyle a dependency of any form of tls, but
nothing more seems appropriate.
("fixed newstyle" is necessary for *anything* that is not
NBD_OPT_EXPORT_NAME)
[...]
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
next prev parent reply other threads:[~2016-04-09 9:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 11:35 [Qemu-devel] [PATCH] Improve documentation for TLS Alex Bligh
2016-04-07 11:51 ` Daniel P. Berrange
2016-04-07 12:13 ` Alex Bligh
2016-04-07 12:36 ` Alex Bligh
2016-04-07 15:35 ` Eric Blake
2016-04-07 15:52 ` Alex Bligh
2016-04-07 13:56 ` Daniel P. Berrange
2016-04-07 14:08 ` Alex Bligh
2016-04-09 9:50 ` [Qemu-devel] [Nbd] " Wouter Verhelst
2016-04-09 10:05 ` Alex Bligh
2016-04-09 10:29 ` Wouter Verhelst
2016-04-07 14:33 ` [Qemu-devel] " Eric Blake
2016-04-07 14:31 ` Eric Blake
2016-04-07 14:57 ` Alex Bligh
2016-04-09 9:55 ` Wouter Verhelst [this message]
2016-04-09 10:06 ` [Qemu-devel] [Nbd] " Alex Bligh
2016-04-09 9:36 ` Wouter Verhelst
2016-04-09 10:04 ` Alex Bligh
2016-04-09 10:33 ` Wouter Verhelst
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=20160409095545.GG19023@grep.be \
--to=w@uter.be \
--cc=alex@alex.org.uk \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=nbd-general@lists.sourceforge.net \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.