Brian P. Hinz [Wed, 19 Nov 2014 23:58:59 +0000 (18:58 -0500)]
More Java viewer clipboard handler fixes
* Override TransferHandler.exportToClipboard method to ensure that
serverCutText updates get sent to the system clipboard. This
wasn't always happening when relying on the super class' paste()
method alone.
* Removed some unnecessary setText() statements and one check for
whether sending client cut text is enabled.
Pierre Ossman [Wed, 19 Nov 2014 13:16:00 +0000 (14:16 +0100)]
Assume inet_pton() is missing on Windows
It's much more difficult to test for this on Windows since the
headers have version guards. Just play it safe and assume it is
missing. We can remove this check when we raise the base requirements
to Vista (or newer).
Brian P. Hinz [Wed, 19 Nov 2014 05:10:46 +0000 (00:10 -0500)]
Major rework of Java viewer clipboard handling
* Clipboard dialog UI significantly improved.
- Fixes issue where scrollpane size did not track dialog size
- Removed unnecessary JPanel
- Adjusted default size of dialog to something more appropriate.
* Clipboard dialog is now a pure clipboard viewer
- Window title now reflects thati fact.
- Eliminates problems with concurrency and updating contents.
- Clipboard dialog now updates contents if a clipbard transfer
occurs and the dialog is visible.
- Prevents possible loop condition when text in the scrollpane
is selected (ie: selection buffer triggers clipboard updates).
* Custom TransferHandler implemented.
- Limits the size of outbound clipboard transfers.
- On Windows and Linux this implementation does not appear to
provoke huge memory spike issue when the transferable is
accessed. Unfortunately, the OSX implemenation still
suffers from this problem, but that is a JRE issue. For the
time being, this at least minimizes the problem. Additionaly,
if an OutOfMemoryError is thrown, it's now caught and an error
is logged rather than the viewer bailing out.
- Vastly simpler implementation - the copy/paste methods inherent
in the JTextArea are utilized for interfacing with the system
clipboard. This eliminates the need for checking permissions,
as well as streamlining the code quite a bit.
Brian P. Hinz [Fri, 14 Nov 2014 02:21:25 +0000 (21:21 -0500)]
Make sure sockets are shutdown in java viewer listen mode
The finalizer method may not be strictly necessary but for the sake
of consistency shutdown the socket listener the same way we do for
a regular TcpSocket.
We should be secure by default, even if it might cause a performance
hit. Those who wish to make that trade off are more likely to notice
the lack of performance than others noticing the lack of security.
Pierre Ossman [Tue, 11 Nov 2014 12:59:01 +0000 (13:59 +0100)]
Make sure we do an initial resize
The local window manager might give us a window of a different size
than the one we request. Make sure that the remote resize setting
gets respected even in this case.
Brian P. Hinz [Wed, 5 Nov 2014 04:56:23 +0000 (23:56 -0500)]
More enhancements to java SSLEngineManager
* Blocking behavior in the read() method was leading to high CPU
usage.
* GC wasn't purging temporary byte arrays used to transfer data
between I/O streams and NIO byte buffers, causing excessive
memory usage.
* Some optimization of read() behavior to reduce the frequency
of blocking operations.
Brian P. Hinz [Wed, 5 Nov 2014 00:57:18 +0000 (19:57 -0500)]
more el5 build enhancements
* Fixes for unresolved dependency issues when linking against static fltk
* Major overhaul of static build. Previously, fltk & tigervnc were built
against the dynamic system libraries (and thus not entirely portable).
All of the X11 libraries required for Xvnc are now built first and
everything is linked against them.
Brian P. Hinz [Wed, 5 Nov 2014 00:45:32 +0000 (19:45 -0500)]
more el5 static build enhancements
Various fixes for linker issues when building fltk statically.
* The native FindX11.cmake module can't be overridden so that
fltk links against the static libraries that we've just built.
* Need to link fltk against libdl.a or else an unresolved
dependency error occurs while linking tigervnc.
* Additional fixes to fix dependency resolution issues when
linking fltk against X11 statically.
Brian P. Hinz [Mon, 3 Nov 2014 04:37:54 +0000 (23:37 -0500)]
Major overhaul of SSLEngineManager
The SSLEngineManager was basically an abomination. The work is now
done as it should be, with the buffers being fed and the engine
deciding when data is consumed or produced. The engine should be
much more robust now as well.
Additionally, although JRE 7 supports the TLSv1.1 and TLSv1.2
protocols, they are not actually enabled by default. The JSSE
reference cites compatibility reasons for this but this doesn't
appear to be the case with the TigerVNC server and they will be
enabled by default in JRE 8.
The regular expression for enabling anonymous DH cipher suites
was too narrow and excluded the elliptic curve ciphers, which
are now ordered ahead of the ephemeral ciphers by the default
security provider.
Lastly, increase the size of the buffer in FdOutStream from 8Kb
to 16Kb. I'm not sure why FdInStream and FdOutStream were
asymmetric to begin with, but 16Kb is the default size for TLS
packets and there seems to be now negative effects on plain
text connections.
Pierre Ossman [Tue, 28 Oct 2014 15:57:05 +0000 (16:57 +0100)]
Put quotes around entire static link variables
CMake is very aggressive about minimising the list of libraries,
so we need to be similarily aggressive about quotes to make sure
we get everything we want and in the correct order.
Pierre Ossman [Fri, 17 Oct 2014 08:36:58 +0000 (10:36 +0200)]
Clean up GnuTLS linking and instructions
GnuTLS can have different crypto backends, and it is rarely gcrypt
these days. So we should not be including that unconditionally,
and should not be pointing people at it either. Also remove the
section about Win32 binaries as those are out of date and probably
insecure. Lastly remove the section about static builds as it is
a general issue and in no way complete with just the GnuTLS portions.
Tim Waugh [Thu, 16 Oct 2014 13:53:17 +0000 (14:53 +0100)]
Don't use MIT-SHM on remote displays.
When run from within 'ssh -X' or 'ssh -Y', MIT-SHM will appear to be
available even though it won't work: the shared memory will be on the
machine running vncviewer, not on the machine running the X server it
displays to. Depending on what shm segments are available on the
machine running the X server, the failure may not be apparent when
checking that MIT-SHM works.
Avoid this by not using MIT-SHM when XDisplayName() indicates we may
not be running locally.
Original bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1072733
Pierre Ossman [Fri, 10 Oct 2014 11:37:35 +0000 (13:37 +0200)]
Use exceptions rather than asserts for for "normal" errors
Although these are rare, they are still not indicative of bugs so
an exception (which ends up in the log and might also be shown to
the user) is more appropriate than an assert. Asserts should only
be used to catch blatant API misuse and similar.
Pierre Ossman [Tue, 30 Sep 2014 15:03:28 +0000 (17:03 +0200)]
Handle PrintScreen and SysReq on Windows
This key requires a bit extra care on Windows. We get wildly
different messages depending on if Alt is pressed or not. The symbol
chosen now follows the standard behaviour on X11.
Brian P. Hinz [Sat, 27 Sep 2014 02:02:47 +0000 (22:02 -0400)]
Fix pointer initialization to prevent NULL events.
Moved call to initEventq() into InitInputDevice() to prevent NULL events from being passed in. The surrounding IFDEF explains why Red Hat BZ bug #820443 just went away, EL6 bumped the version of xorg-x11-server-source to 1.13 at EL6.4.