[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] [PATCH] Document format of strings in one place, limit to 4096 bytes



On 6 Apr 2016, at 21:27, Wouter Verhelst <w@...112...> wrote:

>> +Where this document refers to a string, then unless otherwise stated,
>> +that string is a sequence of UTF-8 code points, which is not `NUL`
>> +terminated, **MUST NOT** contain `NUL` characters, and is of length
>> +4096 bytes or less. This applies to export names and error messages
> 
> I would like to make that a "SHOULD be less than X bytes". A client
> could read the first protocol-demanded bytes, drop the rest, and give a
> warning to the user (while doing a read() into a dummy buffer).

I disagree with that one. What Eric's asking for I think, and
what I am asking for, is an absolute maximum that you can guarantee
will work. If the client merely 'SHOULD' do this, the server MUST
cope when it doesn't. This was one reason why I picked a ridiculously
large length.

This way a server can check the length, and if it's greater than the
limit, simply disconnect, which avoids a code path that's hardly
ever going to be tested to read and discard - it's just ripe for
buffer overflows.

I think to get full benefit, we should go with MUST.

> Also, most of those strings exist solely to make user interaction
> easier. In that context, a 4K string is *way* too long; I'm thinking
> something like 256 seems saner (80 characters, times three because
> UTF-8, round up to the next power of two).

I agree it's way too long (partly for the above reason). I'm happy
to go with 256, but it's conceivable we might want to reconsider
if it's a 'MUST'.

-- 
Alex Bligh







Reply to: