These streams both need to change the corking state temporarily, but it
is important it is restored to the previous state or things might get
messed up.
For the zlib stream it would just leave things uncorked, which still
works but is less efficient.
But for the TLS stream it might make things very unresponsive as the
corking might be left on permanently, delaying packets indefinitely.
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
We use a lot of lengths given to us over the network, so be more
paranoid about them causing an overflow as otherwise an attacker
might trick us in to overwriting other memory.
This primarily affects the client which often gets lengths from the
server, but there are also some scenarios where the server might
theoretically be vulnerable.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
Provides safety against them accidentally becoming negative because
of bugs in the calculations.
Also does the same to CharArray and friends as they were strongly
connection to the stream objects.
Another attempt at solving the compression level change problems. We were still
not detecting the correct approach properly, and hence still getting crashes.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4731 3789f03b-4d11-0410-bbf8-ca57d06f2519
Revert r4498 and fix #3305357 properly. The issue was two-fold: (1) the compress buffer allocated by the Tight encoder was not large enough, and (2) Zlib 1.2.5 can sometimes call deflate(..., Z_BLOCK) within the body of deflateParams(), so we need to check avail_in after calling checkCompressionLevel() to ensure that there is still data left to compress before we call deflate() again.
[Refactoring] Improved rdr::Exception constructor. It now accepts variable
number of arguments.
[Bugfix] Minor compilation fixes (missing #includes)
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3168 3789f03b-4d11-0410-bbf8-ca57d06f2519