We mostly use classical C strings, but the memory management around them
can get confusing and error prone. Let's use std::string for the cases
where we need to return a newly allocated string.
Safely discard large (extended) clipboard contents
Avoid having to buffer everything we want to discard, and instead do it
piece by piece. This is more efficient, and avoids hitting any limits on
the buffering.
Note that this is safe here because we already know we have all the
compressed data. It would not be safe for a general input stream.
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.
Some of these were incorrectly calculated so the server or client would
wait too long before proceeding with decoding.
Change all of these to be a more explicit calculation to avoid such
issues in the future.
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
Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.
We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.
This is required by the protocol so we should make sure it is
enforced. We are tolerant of clients that violate this though and
convert incoming clipboard data.
This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.
Fix crash from integer overflow in SMsgReader::readClientCutText
The length sent by client is U32, but is converted into int. If it was bigger than 0x7fffffff the resulting int is negative, it passes the check against maxCutText and later throws std::bad_alloc from CharArray which takes down the whole server.
All the Streaming API deals with lengths in ints, so we can't tell it to skip that big amount of data. And it is not realistic to expect more than 2GB of clipboard data anyway. So lets just throw rdr::Exception that will disconnect this client and keep the server alive.
Eliminate GCC signed/unsigned warnings related to encodings: The
encoding in the RFB protocol has always been signed, and signed values
are also used in the specification (ie DesktopName = -307 etc). In the
code, however, unsigned types were used in a number of places, but not
all, which causes warnings. This patch fixes the problem by switching
to signed values everywhere.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3968 3789f03b-4d11-0410-bbf8-ca57d06f2519
Remove the "video" feature and its associated custom JPEG handling.
Having the client specifiy the video region is conceptually wrong
and a problem like this should be handled by better encoding selection.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3635 3789f03b-4d11-0410-bbf8-ca57d06f2519
[Enhancements, refactoring] Rationalized functions to control video
rectangle selection and default video rectangle. Added more logging and
improved error checking in the related code.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2753 3789f03b-4d11-0410-bbf8-ca57d06f2519
Removed support for continuous updates, a TightVNC-specific RFB protocol
extension. That extension used to send framebuffer updates continuously, not
waiting for clients' requests. However, it showed bad results with
low-bandwidth connections, due to lack of proper data flow control.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2581 3789f03b-4d11-0410-bbf8-ca57d06f2519
Initial implementation of continuous updates in the server code. This code does not handle framebuffer size changes properly yet. Also, the server does not send the client EndOfContinuousUpdates message yet (documented in doc/rfbproto.tex).
Pierre Ossman
Michal Srb
Peter Åstrand
Constantin Kaplinsky