linux-kernel - Re: Query: Patches break with Microsoft exchange server.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Aug 2010 17:30:34 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Avery Pennarun <apenwarr@...il.com>
Cc:	Jeffrey Hundstad <jeffrey.hundstad@...u.edu>,
	viresh kumar <viresh.kumar@...com>,
	Felipe Contreras <felipe.contreras@...il.com>,
	"git@...r.kernel.org" <git@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Justin P. Mattock" <justinmattock@...il.com>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Valeo de Vries <valeo@...eo.co.cc>,
	Linus Walleij <linus.ml.walleij@...il.com>,
	Matti Aarnio <matti.aarnio@...iler.org>, mihai.dontu@...il.com,
	richardcochran@...il.com, "Gadiyar, Anand" <gadiyar@...com>
Subject: Re: Query: Patches break with Microsoft exchange server.

On Wed, 2010-08-11 at 12:18 -0400, Avery Pennarun wrote:
> 
> Out of curiosity, why fall back to one chunk at a time?  It seems to
> me that IMAP should be able to still support multiple outstanding
> requests in that case, but you'd just get errors on the latter chunks.
> 
> It is just that there was no point optimizing the workaround case?

There wasn't a lot of point in optimising it.

The current logic, shown in the patch I referenced, is to keep fetching
new chunks while the stream position matches the end of the previous
chunk we attempted to fetch.

To handle multiple outstanding requests, especially if they can be
satisfied out-of-order, would have been more complex because the stream
position (in the 'really_fetched' variable) wouldn't necessarily match
anything interesting. We'd have to keep more state, and the whole thing
would get a lot more intrusive.

Also, for the common case where the server isn't broken and the mail
size happens not to fall on a chunk boundary, the current implementation
results in no extra fetch requests. Doing otherwise would either mean
extra fetch requests even for this common case, or would mean even more
complexity to 'catch up' by issuing additional fetch requests as soon as
we realise the server lied about RFC822.SIZE (which is when we receive
the last chunk, and it runs over the size we expected).

It may be that there's a neat and simple way to handle all of the above,
and if so then patches would be welcome -- but personally, I just
couldn't be bothered to think too hard about it. There were more
pressing matters to attend to, like implementing QRESYNC support.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/