Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.
Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).
Move the checks around to avoid missing cases where we might access
memory that is no longer valid. Also avoid touching the underlying
stream implicitly (e.g. via the destructor) as it might also no
longer be valid.
A malicious server could theoretically use this for remote code
execution in the client.
Issue found by Pavel Cheremushkin from Kaspersky Lab
It previously only did a reset of the ZlibInStream object, not the
underlying zlib stream. It also had the side effect of flushing
the underlying stream and disassociating from it.
Clear things up by changing the naming, and introducing a proper
reset function (which is needed by the Tight decoder).
Change fillRect() to take a buffer instead of a pixel
There has been some confusion if fillRect() should accept a buffer
or a pixel. This can cause misrendering if your data is not in the
native endian order. A buffer makes more sense here though, and
is what most of the callers are already assuming, so change the
API to follow that.
Use PixelBuffer objects as the interface for encoders and decoders
This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.
The ZRLE decoder relied on an assert() for boundary checks. A default
Release build however will remove all asserts making it possible to
overrun this buffer. This could be exploited by a malicious server.
This issue has been assigned CVE-2014-0011. Patch by Tim Waugh for
Red Hat.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@5167 3789f03b-4d11-0410-bbf8-ca57d06f2519
min and max changed to vncmin and vncmax. This solves many problems: Some platforms predefines or redefines these symbols. Some platforms have header files which chokes if min or max are defined.