gnutls_certificate_set_x509_trust_file() returns the number of processed
certs and _not_ GNUTLS_E_SUCCESS (0) on success!

Conflicts:
	libvncserver/websockets.c

Do not consume the peeked data if no close frame was detected.

Add common/sha1.h and common/sha1.c so that we have the SHA routines
even if openssl is not available. From the IETF SHA RFC example code.

Remove the UTF-8 encoding hack. This was really just an experiment.

If the protocol passed in the handshake has "binary" then don't base64
encode for the HyBi protocol. This will allow noVNC to request the
binary data be passed raw and not base64 encoded. Unfortunately, the
client doesn't speak first in VNC protocol (bad original design). If
it did then we could determine whether to base64 encode or not based
on the first HyBi frame from the client and whether the binary bit is
set or not. Oh well.

Misc Cleanup:

- Always free response and buf in handshake routine.

- Remove some unused variables.

Move the hixie disconnect hack to websockets.c. Removed
the remaining websockets vars from rfbClientPtr, so all
websockets stuff is hidden behind an opaque pointer.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Added wspath member to rfbClientRec which holds the
path component of the initial websocket request.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

- Add --sslcertfile and --sslkeyfile. These should really be combined
  with the existing x11vnc command line options for SSL support.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

For now, only OpenSSL support is activated through configure, since GnuTLS
is only used in LibVNCClient.

[jes: separated this out from the commit adding encryption support, added
autoconf support.]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

[jes: moved out GnuTLS and OpenSSL support, added a dummy support, to
separate changes better, and to keep things compiling]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This is not completely standard UTF-8 encoding. Only code points 0-255
are encoded and never encoded to more than two octets. Since '\x00' is
a WebSockets framing character, it's easier for all parties to encode
zero as '\xc4\x80', i.e. 194+128, i.e. UTF-8 256.

This means that a random stream will be slightly more than 50% larger
using this encoding scheme. But it's easy CPU-wise for client and
server to decode/encode. This is especially important for clients
written in languages that have weak bitops, like Javascript (i.e. the
noVNC client).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

If the only thing we are waiting on is a WebSockets terminator, then
remove it from the stream early on in rfbProcessClientNormalMessage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Has a bug: WebSocket client disconnects are not detected.
rfbSendFramebufferUpdate is doing a MSG_PEEK recv to determine if
enough data is available which prevents a disconnect from being
detected.

Otherwise it's working pretty well.

[jes: moved added struct members to the end for binary compatibility with
previous LibVNCServer versions, removed an unused variable]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Christian Beier <dontmind@freeshell.org>

http://wiki.qemu.org/VNC_Tight_PNGSigned-off-by: Joel Martin <github@martintribe.org>
Signed-off-by: Christian Beier <dontmind@freeshell.org>

BUG: 256891
Signed-off-by: Christian Beier <dontmind@freeshell.org>

This is required to be able to do proper event loop integration with Qt.
Idea was taken from vino's libvncserver fork.
Signed-off-by: Christian Beier <dontmind@freeshell.org>

Signed-off-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Signed-off-by: Christian Beier <dontmind@freeshell.org>

This reverts commit c1363fa9.

The proper fix was already in 804335f9.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This bug occured when a second telepathy tubes client was connected after
the first one had disconnected and the channel (thus, the screen too)
had been destroyed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>