| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
These files don't use anything from this header, so remove the include.
This exposes some missing includes in other places, though. So add an
explicit include in the files that were relying on an indirect
inclusion.
|
| |
|
|
|
|
|
|
| |
It's more standard and familiar than our custom CharArray type, and it
still gives us automatic freeing of the buffer.
We could probably have used std::unique_ptr instead, but we are
currently targeting older compilers where C++11 isn't standard yet.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Avoid our own custom types in favour of what's already included with
C++.
|
| |
|
|
|
| |
Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.
|
| |
|
|
| |
The flags should always be empty anyway.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
We have no need for this abstraction so let's keep things simple.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2585 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
VideoRectangleSelection messages.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2560 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
| |
|
|
|
|
| |
message is read but ignored (only a message will be written to stderr).
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2559 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
| |
|
|
|
|
| |
does not handle framebuffer size changes properly yet. Also, the server does not send the client EndOfContinuousUpdates message yet (documented in doc/rfbproto.tex).
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2251 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
More changes will follow.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
