Brian P. Hinz [Fri, 26 Dec 2014 04:51:36 +0000 (23:51 -0500)]
Major update of EL5 build
The patches required for the 2014-12-09 Xorg CVE advisory would not
have been feasible to back-port to the 1.7 version of Xorg that we
were previously using to built against for EL5 and the generic
binaries. However, building the newer version of Xorg required
some fairly extensive re-tooling. In a nutshell, here's what was
done:
* The build is now done against Xorg X117R7, with all CVE patches
(taken from debian sources) applied. Note that this requires
updating various packages beyond the versions readily available
for EL5. This included things like automake, autoconf, libtool,
m4, and flex. Wherever possible, the EL6 rpm was used unaltered.
The most chalenging package to upgrade was libxml2, which was
necessary to supply the python26-libxml2 requirement from mesa.
* Mesa libGL is now supplied with the package, installed in the
%{_libdir}/tigervnc directory. The Xvnc binary is linked using
an rpath so that we always link against our version of libGL.
This was done to prevent linker errors with the generic binaries
in the case where the distro supplied libGL is built with
different options (in particular, kernel versions < 2.4.20 do
not support glx-tls, so the generic binaries would likely break
whenever used on newer distros that build libGL with glx-tls
turned on by default). Additionally, this allows swrast_dri.so
to be bundled without worrying about overwriting the distro
supplied library.
* A static libsha1 is built for Xorg to link against. The EL5
version of libgcrypt does not satisfy Xorg's requirements,
and linking against OpenSSL creates nearly a dozen runtime
dependencies.
Pierre Ossman [Mon, 26 Jan 2015 13:37:04 +0000 (14:37 +0100)]
Restructure Xvnc/libvnc.so code to avoid C++ header hacks
The internal Xorg headers are very incompatible with C++ and we've had
to resort to all kinds of hacks in order to include them in our C++
code. This approach isn't really viable long term so restructure things
so that we have a glue layer written in C that bridges the Xorg core
with the RFB classes.
Brian P. Hinz [Fri, 26 Dec 2014 05:53:33 +0000 (00:53 -0500)]
Remove support for openSUSE 11.4
Project Evergreen stopped supporting 11.4 in October and it's not feasible to
back-port the patches for the Xorg 2014-12-09 CVEs, so as a result we can no
longer provide pre-built packages for this distribution. The genric binaries
can be used instead.
Pierre Ossman [Tue, 2 Dec 2014 14:13:22 +0000 (15:13 +0100)]
Make sure attributes propagate through security wrappers
Both SSecurityVeNCrypt and SSecurityStack are wrappers around other
security objects, so they need to delegate the properties of those
sub-objects properly.
Pierre Ossman [Tue, 2 Dec 2014 13:33:17 +0000 (14:33 +0100)]
Limit access to non-shared mode
A read-only client should not be allowed to kick out other clients.
It will be forced into shared mode, or refused the connection, depending
on the neverShared parameter.
Brian P. Hinz [Sat, 22 Nov 2014 01:11:14 +0000 (20:11 -0500)]
SPEC file cleanup
* Removed the hard coded snap tag, if needed it should be passed in
via "rpmbuild --define 'snap ...'".
* Changed the hard coded version to "@VERSION@" to make it clear
that the copy of the spec file in the repository needs to be
updated manually.
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.
Michal Srb [Mon, 10 Nov 2014 07:15:41 +0000 (09:15 +0200)]
Allow SSecurity to specify AccessRights for SConnection.
SConnection has AccessRights property that specifies what connected client can
do. Set this property to value given by SSecurity after successful
authentication. This way individual SSecurity subclasses can accept clients but
restrict their access.
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.