[Nbd] These revelations will convert you into a rich person

[Nbd] Happy Ugadi 2016 from Sobha Dream Acres

-- ___ Nbd-general mailing list

[Nbd] The future is finally looking good for you in 2016

Re: [Nbd] [PATCHv4] Document NBD_CMD_CLOSE

On 8 Apr 2016, at 04:31, Eric Blake wrote: > Should we be sticking this in the Experimental Extensions section, until > we have an implementation? Not every change needs go through 'experimental'. You'll have an implementation in about 10 seconds if Wouter likes this as I have it here. That's

Re: [Nbd] [PATCHv4] Document NBD_CMD_CLOSE

On 04/07/2016 02:12 PM, Alex Bligh wrote: > This commit adds documentation for NBD_CMD_CLOSE which provides a > safer way for the client to close connections, and indicates > unambiguously to the server and client whether a close is safe. > > Signed-off-by: Alex Bligh > --- > doc/proto.md | 72

Re: [Nbd] [PATCH v6 1/2] doc: Clean up wording about INFO then GO response

On 7 Apr 2016, at 23:33, Eric Blake wrote: >> This back compatibility thing is the thing I thought should be a 'MUST' >> but you and Wouter think (and I accepted) should be a 'SHOULD'. But >> it should not be a 'should'. It's now - well it is >> after MAY/SHOULD/MUST patch - a SHOULD elsewhere (

Re: [Nbd] [PATCH v6 1/2] doc: Clean up wording about INFO then GO response

On 04/07/2016 04:30 PM, Alex Bligh wrote: >> >> diff --git a/doc/proto.md b/doc/proto.md >> index f117394..a81b59c 100644 >> --- a/doc/proto.md >> +++ b/doc/proto.md >> @@ -743,6 +743,10 @@ Therefore these commands share common documentation. >> to requests for exports that are unknown. This is

Re: [Nbd] [PATCH v6 1/2] doc: Clean up wording about INFO then GO response

> > diff --git a/doc/proto.md b/doc/proto.md > index f117394..a81b59c 100644 > --- a/doc/proto.md > +++ b/doc/proto.md > @@ -743,6 +743,10 @@ Therefore these commands share common documentation. > to requests for exports that are unknown. This is so that clients > that have not negotiated

Re: [Nbd] Current status of patches

On 7 Apr 2016, at 22:26, Eric Blake wrote: > Merge conflicts with the recent: > [WV]: Fix typos: s/NDB/NBD/g > [AB]: Document format of strings in one place, limit to 4096 bytes > > and you're already basing other patches on top of it. Since I've > already got a wording tweak that will also co

Re: [Nbd] [PATCHv4] Improve documentation for TLS

On 7 Apr 2016, at 21:35, Eric Blake wrote: > grammar tweak: > s/ and either /, / sigh. fixed. Remembered to add your Reviewed-by: tag too. -- Alex Bligh signature.asc Description: Message signed with OpenPGP using GPGMail --

[Nbd] [PATCHv5] Improve documentation for TLS

* Call out TLS into a separate section * Add details of the TLS protocol itself * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can be initiated from either side (as required by the TLS standard I believe and as actually works in practice) * Clarify what is a requirem

[Nbd] [PATCH v6 0/2] SHOULD / MUST / MAY

v6: add another wording fixup, then rebase to master Since the two patches conflict, and since Alex' patch is a conflict magnet for later patches, I'm hoping we can get both of these in sooner rather than later. Alex Bligh (1): docs/proto.md: Clarify SHOULD / MUST / MAY etc Eric Blake (1): d

[Nbd] [PATCH v6 2/2] docs/proto.md: Clarify SHOULD / MUST / MAY etc

From: Alex Bligh These are changes which possibly have semantic effect * Clarify that SHOULD / MUST / MAY etc. when in capitals have an RFC 2119 meaning using the wording within that RFC. * Fix some lowercase use of these words which actually were meant to be uppercase. * Fix some lowercas

[Nbd] [PATCH v6 1/2] doc: Clean up wording about INFO then GO response

The wording was a bit repetitive, but at the same time had a flaw: it implied that INFO(name1) followed immediately by GO(name2) would give the same transmission flags. Make it clear that the identical success response is only in the case of the same parameters. Meanwhile, swap paragraph ordering

Re: [Nbd] Current status of patches

On 04/07/2016 03:43 AM, Alex Bligh wrote: > Eric, Wouter, > > I put together a note for my own memory on where I think the various patches > to doc/proto.md (and related code patch(es)) circulating over the last few > days are. > > I think "[PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc

Re: [Nbd] [PATCHv4] Improve documentation for TLS

On 04/07/2016 02:07 PM, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I believe > and as a

[Nbd] [PATCHv4] Document NBD_CMD_CLOSE

This commit adds documentation for NBD_CMD_CLOSE which provides a safer way for the client to close connections, and indicates unambiguously to the server and client whether a close is safe. Signed-off-by: Alex Bligh --- doc/proto.md | 72 +

[Nbd] [PATCHv4] Improve documentation for TLS

* Call out TLS into a separate section * Add details of the TLS protocol itself * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can be initiated from either side (as required by the TLS standard I believe and as actually works in practice) * Clarify what is a requirem

Re: [Nbd] [PATCHv3] Improve documentation for TLS

Eric, > Qemu's initial implementation of TLS in the client is binary (you either > want TLS or plaintext; there's no way to connect to a server and then > decide whether to upgrade to TLS - a plaintext client will never use TLS > of an OPTIONALTLS server). In TLS mode, the client always sends > N

Re: [Nbd] [PATCHv3] Improve documentation for TLS

On 04/07/2016 12:32 PM, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I believe > and as a

Re: [Nbd] [PATCHv3] Document NBD_CMD_CLOSE

On 04/07/2016 01:01 PM, Alex Bligh wrote: > This commit adds documentation for NBD_CMD_CLOSE which provides a > safer way for the client to close connections, and indicates > unambiguously to the server and client whether a close is safe. > > Signed-off-by: Alex Bligh > --- > doc/proto.md | 72

[Nbd] [PATCHv3] Document NBD_CMD_CLOSE

This commit adds documentation for NBD_CMD_CLOSE which provides a safer way for the client to close connections, and indicates unambiguously to the server and client whether a close is safe. Signed-off-by: Alex Bligh --- doc/proto.md | 72 +

Re: [Nbd] [PATCHv2] Document NBD_CMD_CLOSE

Eric, >> +* `NBD_CMD_CLOSE` (7) >> + >> +A close request. The server MUST handle all outstanding >> +requests (there should be none by the spec), and then MUST send an >> +`NBD_REP_ACK`. The server MUST NOT send an error reply. >> +The server MUST NOT send anything after sending an

Re: [Nbd] [PATCHv2] Document NBD_CMD_CLOSE

On 04/07/2016 10:05 AM, Alex Bligh wrote: > This commit adds documentation for NBD_CMD_CLOSE which provides a > safer way for the client to close connections, and indicates > unambiguously to the server and client whether a close is safe. > > Signed-off-by: Alex Bligh > --- > doc/proto.md | 69

[Nbd] [PATCHv3] Improve documentation for TLS

* Call out TLS into a separate section * Add details of the TLS protocol itself * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can be initiated from either side (as required by the TLS standard I believe and as actually works in practice) * Clarify what is a requirem

Re: [Nbd] [PATCHv2] Improve documentation for TLS

Eric, >> +++ b/doc/proto.md >> @@ -286,6 +286,289 @@ S: (*length* bytes of data if the request is of type >> `NBD_CMD_READ`) >> This reply type MUST NOT be used except as documented by the >> experimental `STRUCTURED_REPLY` extension; see below. >> >> +## TLS support >> + >> +The NBD protocol su

Re: [Nbd] [PATCHv2] Improve documentation for TLS

On 04/07/2016 09:33 AM, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I believe > and as a

Re: [Nbd] [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 7 Apr 2016, at 17:10, Eric Blake wrote: > I'm also starting to think that it is worth FIRST documenting an > extension for advertising block sizes, so that we can then couch > BLOCK_STATUS in those terms (a server MUST NOT subdivide status into > finer granularity than the advertised block si

Re: [Nbd] [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 04/07/2016 04:38 AM, Vladimir Sementsov-Ogievskiy wrote: > On 05.04.2016 16:43, Paolo Bonzini wrote: >> >> On 05/04/2016 06:05, Kevin Wolf wrote: >>> The options I can think of is adding a request field "max number of >>> descriptors" or a flag "only single descriptor" (with the assumption >>> t

[Nbd] [PATCHv2] Document NBD_CMD_CLOSE

This commit adds documentation for NBD_CMD_CLOSE which provides a safer way for the client to close connections, and indicates unambiguously to the server and client whether a close is safe. Signed-off-by: Alex Bligh --- doc/proto.md | 69 +

Re: [Nbd] [PATCH] Document NBD_CMD_CLOSE

Eric, >> @@ -608,6 +609,11 @@ The following request types exist: >> The values of the length and offset fields in a disconnect request >> are not defined. >> >> +A client SHOULD NOT send `NBD_CMD_DISC` if `NBD_FLAG_SEND_CLOSE` >> +is set in the transmission flags field, but SHOULD

Re: [Nbd] [PATCH] Improve documentation for TLS

Eric, (this crossed with v2) On 7 Apr 2016, at 16:35, Eric Blake wrote: > On 04/07/2016 06:36 AM, Alex Bligh wrote: >> >> On 7 Apr 2016, at 13:13, Alex Bligh wrote: >> >>> I guess it's worth documenting >>> this, though I thought it was obvious. >> >> The next version will have this section

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 07/04/2016 17:35, Pavel Borzenkov wrote: > > On 05/04/2016 06:05, Kevin Wolf wrote: > > > The options I can think of is adding a request field "max number of > > > descriptors" or a flag "only single descriptor" (with the assumption > > > that clients always want one or unlimited), but maybe y

Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On Tue, Apr 05, 2016 at 03:43:08PM +0200, Paolo Bonzini wrote: > > > On 05/04/2016 06:05, Kevin Wolf wrote: > > The options I can think of is adding a request field "max number of > > descriptors" or a flag "only single descriptor" (with the assumption > > that clients always want one or unlimite

Re: [Nbd] [PATCH] Improve documentation for TLS

On 04/07/2016 06:36 AM, Alex Bligh wrote: > > On 7 Apr 2016, at 13:13, Alex Bligh wrote: > >> I guess it's worth documenting >> this, though I thought it was obvious. > > The next version will have this section: > > ### Downgrade attacks > > A danger inherent in any scheme relying on th

[Nbd] [PATCHv2] Improve documentation for TLS

* Call out TLS into a separate section * Add details of the TLS protocol itself * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can be initiated from either side (as required by the TLS standard I believe and as actually works in practice) * Clarify what is a requirem

Re: [Nbd] [PATCH] Document NBD_CMD_CLOSE

On 04/07/2016 07:55 AM, Alex Bligh wrote: > This is offered as a straw-man for comment. The rationale for it > has been discussed on-list and is in the documentation. > > This applies on top of: >[PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc > > so it can take advantage of the 'exp

Re: [Nbd] [PATCH] Improve documentation for TLS

On 7 Apr 2016, at 15:31, Eric Blake wrote: >> +### TLS versions Certificates, authentication and authorisation > > s/versions/versions,/ ? ok >> + >> +NBD implementations supporting TLS MUST support TLS version >> +1.2, and MAY support other (earlier or later) versions of >> +TLS/SSL. > > Al

Re: [Nbd] [PATCH] Improve documentation for TLS

On 04/07/2016 05:51 AM, Daniel P. Berrange wrote: >> + >> +There are four modes of operation for a server. The >> +server MUST support one of these modes. >> + >> +* The server operates entirely without TLS ('NOTLS'); OR >> + >> +* The server makes TLS available (for all exports) and >> + it is a

Re: [Nbd] [PATCH] Improve documentation for TLS

On 04/07/2016 05:35 AM, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I believe > and as a

Re: [Nbd] [PATCH] Improve documentation for TLS

Daniel, >> Could you describe how a downgrade attack might occur? It's >> always open to the client to refuse to access an export (or >> the server as a whole) unless TLS is negotiated, as I make >> clear here (see last phrase). > > Right, so that's OK if the client is implementing FORCEDTLS. Cl

Re: [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 01:13:10PM +0100, Alex Bligh wrote: > Daniel, > > On 7 Apr 2016, at 12:51, Daniel P. Berrange wrote: > > > IMHO, we should not permit what you call OPTIONALTLS or SELECTIVETLS, > > because these open possibilities for a MITM to perform downgrade > > attacks, where the MIT

[Nbd] [PATCH] Document NBD_CMD_CLOSE

This is offered as a straw-man for comment. The rationale for it has been discussed on-list and is in the documentation. This applies on top of: [PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc so it can take advantage of the 'exposes' language. Signed-off-by: Alex Bligh --- doc/pro

Re: [Nbd] Current status of patches

On 7 Apr 2016, at 13:41, Eric Blake wrote: > On 04/07/2016 03:43 AM, Alex Bligh wrote: >> >> I think "[PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc" >> is probably ready to merge now. Wouter's points were all addressed >> in v5, and Eric OK'd v5 apart from some issues re NBD_OPT_GO t

Re: [Nbd] Current status of patches

On 04/07/2016 03:43 AM, Alex Bligh wrote: > Eric, Wouter, > > I put together a note for my own memory on where I think the various patches > to doc/proto.md (and related code patch(es)) circulating over the last few > days are. > > I think "[PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc

Re: [Nbd] [PATCH] Improve documentation for TLS

On 7 Apr 2016, at 13:13, Alex Bligh wrote: > I guess it's worth documenting > this, though I thought it was obvious. The next version will have this section: ### Downgrade attacks A danger inherent in any scheme relying on the negotiation of whether TLS should be employed is downgrade attacks

Re: [Nbd] [PATCH] Improve documentation for TLS

Daniel, On 7 Apr 2016, at 12:51, Daniel P. Berrange wrote: > IMHO, we should not permit what you call OPTIONALTLS or SELECTIVETLS, > because these open possibilities for a MITM to perform downgrade > attacks, where the MITM runs TLS to the real server, but runs no-TLS > to the real client. Coul

Re: [Nbd] [PATCH] Improve documentation for TLS

On Thu, Apr 07, 2016 at 12:35:59PM +0100, Alex Bligh wrote: > * Call out TLS into a separate section > > * Add details of the TLS protocol itself > > * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can > be initiated from either side (as required by the TLS standard I be

Re: [Nbd] doc/proto.md: TLS question

Wouter, On 6 Apr 2016, at 22:04, Alex Bligh wrote: > I think this should thus be deleted. No, it must stay. There's currently no way to detect whether a particular export supports TLS. If the client wants to connect to an export that the server only exports th

[Nbd] [PATCH] Improve documentation for TLS

* Call out TLS into a separate section * Add details of the TLS protocol itself * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can be initiated from either side (as required by the TLS standard I believe and as actually works in practice) * Clarify what is a requirem

[Nbd] 2/2.5/3 BHK Apartments in Devanhalli, Bengaluru

-- ___ Nbd-general mailing list

Re: [Nbd] [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

On 05.04.2016 16:43, Paolo Bonzini wrote: > > On 05/04/2016 06:05, Kevin Wolf wrote: >> The options I can think of is adding a request field "max number of >> descriptors" or a flag "only single descriptor" (with the assumption >> that clients always want one or unlimited), but maybe you have a bet

[Nbd] Current status of patches

Eric, Wouter, I put together a note for my own memory on where I think the various patches to doc/proto.md (and related code patch(es)) circulating over the last few days are. I think "[PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc" is probably ready to merge now. Wouter's points were a

[Nbd] Get protection for your car at a price you can afford.

[Nbd] Your credit card application is approved!

-- ___ Nbd-general mailing list Nbd-

[Nbd] We are ready for the real estate bill

-- ___ Nbd-general mailing list Nbd-

Re: [Nbd] [PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc

Eric, >> -The server MUST NOT fail an NDB_OPT_GO sent with the same parameters >> -as a previous NBD_OPT_INFO which returned successfully (i.e. with >> +The server MUST NOT fail an `NDB_OPT_GO` sent with the same parameters >> +as a previous `NBD_OPT_INFO` which returned successful